techno.blog("Dion")

Man, I haven’t been as excited about a development tool as I am about Joe Stump’s Sprint.ly in a looooong time (GitHub is probably the last time).

It is an incredibly timely tool for me. I use a variety of small tools for different projects. Open source hacking vs. large projects at work with a bunch of different teams.

I enjoy Pivotal Tracker, and have even begun to appreciate why I have to use JIRA…. and thus, for some projects I am forced to use both. This is far from ideal, and every few months I look to see if I can shoot one in the head to focus on one tool.

For some context, I should write down my high level believes around creating software products, and then we can talk tools.

If I try to distill my beliefs I get:

Responsibility

Everyone in the team builds software products (and should be empowered). Great organizations push down responsibility (yup, even Steve Jobs). This enables teams to have minimal bottlenecks, and by enabling the teams they will enjoy their work more, and will care. How many situations have you seen that end up with “well, some bozo boss told me to do that…. so duh, I did it… and of course it was dumb!”

Communication

The closer everyone is to a shared understanding the better. There are many levels of communication, on a variety of themes. In general I believe that a business/group should trickle down: business goals -> strategy -> high level roadmap -> products that fullfil.

Planning

Some people tell me that agile == an excuse not to plan. This seems to stem from people thinking that “we can’t see into the future” means “we shouldn’t plan, and instead react.” This is almost always a false assumption :)

If you aren’t thinking about the future and “skate to where the puck will be” then you can only ever slowly evolve. As an example, right now at my company we are trying to re-imagine what commerce and retail could be like for customers 5 years from now, and we can back track from that. Not being able to see in the future means that you end up making bets, but it is critical. This planning and thinking is all about product vision. It is not set in stone, and it can evolve itself. Steve Jobs thought that the network computer would be the future at one point (he was friends with Larry after all ;) but we still have hard drives.

Execution

I don’t favor complex planning tools. I like the basics. There are a list of things that need to get done for your product. You have people to work on making this happen, and you can prioritize the work. You need to keep on top of the queue of work and keep changing the prioritize tactically.

To execute you need all roles firing. Product management, engineering, UX, QA. The role of “stories” can give a high level common language that can be a great starting off point to interface these roles.

Although you can’t look into the future, the longer that a team has worked together, and the longer a project is in place…. the better chance you have of knowing how true your view of the project is.

So, with this all in mind, how do some of the tools stack up?

Pivotal Tracker

Tracker has been a great tool for development. It fits in to a lean methodology and the “queue of work” mentality. I find the UI very simple, and with one screen and keyboard shortcuts all interactions are fast.

The integrations, including Campfire (critical for communication), JIRA and others are crucial…. since no One Tool has been the solution.

There are some things that I don’t like though:

• Although each story has a URL, if you go to the URL you get the entire UI loading… and then your item pops in (vs. a simple page with just that content)
• Stories have tasks, but you can’t assign different people to those tasks. So, if you wanted to have a QA task and a design task as well as a development task…. the assignment breaks down. With JIRA you could use subtasks just fine, or you could use an assignment workflow
• No ability to make bulk changes
• Searching is a lil weak
• Tags end up being the Solution For Everything
• “The application has died. Please reload.”
• Reporting is weak. Tracking the backlog and tying to versions etc is hard.

JIRA

JIRA is an issue tracker. It is incredibly complex compared to tracker (and Lighthouse and Trac …) and you can extend the data and workflow behind it. The complexity is frustrating to many though. Having to grok Projects, Versions, Components, labels, issues….. is more than you often need.

It does let you have nuanced views on the data though, so you can make it do the right thing for the different roles. Searching is rich (there is a query language for the beast! eek :/) and you can slice or dice all day long.

I do not like JIRA for main development and tracker is for that…. but JIRA comes into play due to QA and other groups knowing it well.

I have tried Greenhopper a few times, trying to see if that view can take the place of Tracker, but it is overly complex for my needs and a frustrating experience. First, you need to configure things (setup a Ranking Field blah blah), and then you think that you should be able to drag things around and it never quite works right for me.

There are other things that bug me about JIRA too, such as:

• The emails. They hide the interesting data and I need to look carefully to see what the heck it is trying to tell me!
• The performance of onjira.com…. I keep picturing OFBiz trying to keep up
• How is there not a simple Campfire integration???? Really? I have to use Hubot?

Asana

I enjoyed meeting the Asana team, not only because it was fun to chat about their platform (Fibers and such), but also because they are trying to make Enterprise software not suck. The meta-system for master-detail is definitely something that you can use for planning and executing software products. It was a little too meta for me though (this was early beta) and I wanted some more features specific for software than custom fields to use. Also, the fact that there wasn’t a way to access on mobile or API to tie into integrations, mean that it isn’t there yet for me.

GitHub

GitHub is amazing. It is an integral part of my software development and I think that these guys and this product could keep growing to Own It All if they so fancy. I like GitHub Issues, but they are still a little too simplistic for me for larger projects. For some open source projects of mine they are perfect, and having the great integration with code, commits, and pull requests is spot on. Working with larger cross functional teams though…. not so much. I again need more than “well you can use tags and a taxonomy to kinda make that work.” I very much do appreciate their vision, and how fast the tool is to use!

There are so many other tools across the stack (Lighthouse, Trac, VersionOne, ….) but I won’t go on and on.

Sprintly

If I look at the things that I believe in (up top), and the things in tools that I have used over the years that I like and don’t like, and then map this onto a “tool I wish I had” I quickly see that a lot of those features map on to Sprintly.

I haven’t even used it yet, but am very much looking forward to giving it a go. It seems to be the sweet spot around:

• Thinks about cross functional teams
• Stories and tasks in a way that makes sense (assign tasks to different people)
• Great dashboard: visibility FTW!
• GitHub integration up the wazoo
• Looks beautiful!

It looks great already and it is probably a 0.6. I hope they keep pushin’ and make I can use GitHub+Sprintly as my go-to pair…. and I can leave the rest behind.

Has anyone been using it and thinks it stacks up? What other tools am I missing? Michael Mahemoff is a Trello fan :)

I am reading A Theory of Fun written and illustrated by Raph Koster. It is a fantastic little book that the renaissance man of Mozilla, Atul Varma, passed over (to Ben actually, and I nabbed it for a quick read!)

In theory, the book is about computer games, but in practice it is applicable to Everything. The content is deep in a way that has you applying it to your own areas of interest. For me, my thoughts kept rolling over to two loves…. software development, and parenting (education).

Some of the early thoughts were about how the brain works, and the “chunking” that the brain does with information. We are not robots or computers. Most of us are unable to recall exact events. If someone says “what searches were run at 12:34pm last Sunday” to Google, it could tell you. If you asked me to explicitly name the events of the day, the detail would be replaced by the general. “Got out of bed, got dressed, went to work” etc. The brain is chunking away the details that don’t matter.

You can then jump from that to think about what happens when you master something. We talk about “muscle memory” which has less to do with muscle, and more to do with the brain. There is research that shows that thinking about actions helps grow muscle memory…. so Chevy Chase is right when he told us to be the ball This is old hat for sporting chaps who are often told to think about events with positive outcomes, preparing for that fantastic cross from Cristiano Ronaldo and your split second attempt to glance a header into the bottom corner. Practice is more than physical.

It is interesting to think about how the brain constantly internalizes patterns. Raph mentions the obvious data point of how our eyes see our nose, but we don’t see it. In fact, most of the time we are filling in the blanks. There is a reason why eye witnesses are so awful. We think that we “see” things in the literal sense, but in fact we are seeing our own doctored reality.

Anyway, how does this relate to software again?

Creating the right path for a challenge

If something is too easy, we find it boring. If something is too hard, we dismiss it and don’t want to play. We can see this with Tic Tac Toe (discussed in the book). If you are playing a kid, they tend to lose all the time, until they grok it and then they can draw all the time and it instantly becomes no fun.

To do our best work, we need to cut the right path. When I think back to the best teachers that I had, they were the ones that created that path. They balanced enough repetitive thinking so my brain could happily learn patterns (it reeeeally likes patterns), but in a way where you were constantly growing and building. We have all heard the following said: “That teacher was great. They made Math fun.” Sometimes you may think it was the funny teacher, or the young teacher who let you get away with anything that would be the most fun. For me though, that wasn’t the case at all. It isn’t fun to not push yourself, or feed the brain at all. If you think back, you will probably find that your favourite teachers actually had very high expectations of you, they just also gave you a path with a good learning curve.

ASIDE: This is probably why I have found that my best teachers weren’t necessarily the smartest ones. It is hard to teach a tough concept to a student when it is innate and obvious in your own mind. A seminal moment for me in Math was when I sneakily changed teachers in high school.

The goal of the team on a software project should be to recreate this curve. That arc of the project needs to keep you growing in a way that has you enjoying the growth.

Why Rails?

There is another tension in software development. Once you get really good at a given technology, when does it make sense to jump to the next one versus staying the course?

I have been through this quite a few times. Take Web development as an example. I had my own Web framework when that was all the rage, and it evolved with the needs of my projects. I knew it intimately, it was nice and lean as it only had what I wanted in it, and there was room to grow. Fast forward to 2009, am I better off having fulfilled projects across a series of frameworks or platform, or would I actually be better off staying the course with my Web.pm and friends?

My personal framework breaks down fairly quickly when you think about working in teams with varied backgrounds, but beyond that I also find myself back thinking about “fun”.

A lot of developers jumped onto the Rails bandwagon as they thought it made Web dev fun again. Writing code that does real stuff feels more “fun” to me than the scaffolding of XML required by the big Java frameworks of the time.

I also believe that Rails did a fantastic job at giving people one of those nice paths to success. It is “easy” to get started using it, but there is enough to learn to keep you enjoying life in the framework.

There are a huge number of other factors of course, and the marketing and community that DHH created have a lot to do with the path that Rails itself has taken (good and bad). Both marketing and community are key as they can change the needle on perceived fun which is all that really matters.

Refactoring as a way to help the path

How can you help build the magic Happy Path? One way is by giving yourself the gift of time, and using it correctly.

Over time, code on a project can get crufty. If you are running fast and hacking together new features your source will become sludge and your velocity will suffer. At this point in time the coding becomes Less Fun to deal with (productivity goes down) and the brain runs into a steeper path which borders on “too hard”. Give yourself the gift of frequent refactoring and you may well be able to do the gardening that will keep the path green. Agile folk have talked about the benefits of paying forward through refactoring, and using testing to enable safety as you change things. You may also enjoy the act and art of refactoring itself, and creating functionality afterwards.

Refactoring also offers something else. It offers a way to better yourself as a developer. If you only ever write an API once, then you can only learn so much. If you are continuously evolving your systems you are trying out new tactics and approaches which you learn from.

“Project Plan” == Happy Path

This comes together and makes me want to revisit the light “project plan” and make sure that it is leading ahead, shining the light on the happy path itself.

Chunking your code

As I thought about the fact that our brain chunks what it does, and how it is probable that it doesn’t see the reality of the code, it makes me wonder. How does this affect our code? Shortly after we write it, we forget what we did. We probably forget some of the reasoning that made sense at the time. You may remember to put some inane comments in there if you are lucky, but that still won’t help too much with the big picture.

Since we can’t keep the exact code in our brain, how does that affect what we write? It makes me feel like the importance of a clean architecture, small modules, and simplicity really kicks in. Patterns can really help here too. When you cracked open an early Rails project, you would be able to understand a lot about the project based on the patterns that you are used too. That enabled a higher level of thinking about the project. If you can create your own higher level modules that build on each other then a lot of understanding comes along with you when you crack open a nice small module.

DSLs: Patterns are brain food

The DSL movement continues to grow in some ways (they had a DSL conference!) and in others it has always been there (SQL is a DSL!)

When you think of the pattern matching brain food, it makes me think of DSLs. Once more, if you let your brain learn those DSLs then it makes life easier to build products based on them.

Functional Programming == Pattern Matching

And the pattern matching logic of the brain brings me to another hot spot of current dev talk….. the re-rise of the functional languages!

Testing builds stairs

There aren’t many insights here per se. Refactoring, simple code, keeping things fun…. all good stuff that we kinda know.

We have all been on projects that aren’t fun, and progress is sloooooow. On the other side, we have also all been on projects where you can’t step away from the computer.

I had a reprieve of this only a short week ago. I was staring at some functionality in a project that was a lot of messy work and my brain wasn’t ready for it. It was only when I took a step back and plotted the Happy Path that things came together. By plotting “first, lets just get up the first stair” it kept me engaged. Then I continued to climb the stairs and the brain kicked in. Before I knew it I had reached the next level and things were done.

One way to build out the stairs on the path is by creating unit tests. Knowing that you have 40 tests completed lets you focus on the first. You know that if you keep learning and climbing you will get there.

If unit tests only helped you build the foundation for the stairs then rather than being “a waste of time and code we need to maintain” they become something much more. And of course, this adds to the fact that they are insurance for the future, and help you become a client of your own APIs immediately.

As you can see, I thoroughly enjoyed reading the book and day dreaming my way to apply it to software.

I got an email from Michael Slaby, CTO of Obama’s campaign, as I am sure a ton of people did who somehow said they are software developers.

I think that Barak’s webpage is by far the best of all candidates, and it even did well on my super Tuesday Ajax endorsements.

For a second I had the thought of packing up the family, asking Google for a six mouth sabbatical, and heading to Boston to try to make sure Obama wins the presidential election. Wouldn’t it be great to say to my grandkids “Yes Bobby, after 8 of the worst years the US has ever had I got in the trenches to make a difference. Not with a sword, but with this thing we used to call a ‘computer’.”

Really has kicked in, but it would be a real wild ride.

How about you?

From day one, this campaign has used technology to help build a movement of millions of people.

As we broaden this effort and look toward the general election, we’ll increasingly rely on online tools to empower these supporters.

You once expressed an interest in helping out on the campaign or told us you work at a technology company.

Right now, you can be part of the campaign that’s using the Internet to revolutionize presidential politics — and play a key role in the movement that will change this country.

http://my.barackobama.com/developer