Good enough software

So the first question is what “good enough software” actually means? My current definition is rather simple: whatever makes the business owner happy. I didn’t mention any technical characteristics on purpose because business very often neither cares nor understands them.
Doesn’t it mean that we are doomed to low quality, crappy software that we can’t possibly be proud of? I don’t think so. I’m yet to see healthy, profitable business that thinks its IT delivers features too fast. And quality is a must have when you want to achieve sustainable, high velocity.
The fact that a team can complete tasks quickly doesn’t mean they work on the right tasks. As software engineers we are perfectionists and this is great but at the same time it means that we can become very easily victims of gold plating. To make sure this happens as rarely as possible (I don’t think this can be fully prevented :) ) we need to make sure that every significant activity is driven by the business. It goes without saying that having a prioritised back log is a must have nowadays. But then there are other, smaller tasks that very often are not driven by the business though they should.
One of them is bug fixing. It’s the business that should decide if a particular bug is worth fixing or not. This might be hard to digest for developers and QAs but it is the business that pays our salaries and it should decide what we work on. Our job is to make sure the business is aware of the trade-offs and in this way can make informed decisions. Same logic applies to Definition of Done, build versus buy and so on.
As a side effect of getting the business involved in the process of building software by IT we have a good chance to establish trust between those two which unfortunately is not very common.
Companies rely more and more on IT because it’s the best way to achieve their goals. But we have to keep in mind that if they find a better way they will switch away from IT in no time. So let’s make sure we stay No.1 as long as possible by building good enough instead of perfect software.

Healthy team

I’ve had recently a few conversations about what constitutes a great software development team and I found myself using phrase ”healthy team” a lot. It’s a rather vague expression so the goal of this blog post is to explain what I mean by it.

People

A healthy team consists of people that share the same vision (the end goal of the project) and the same basic principles (high care factor, working as a team, not leaving broken build overnight, etc.). Even one person that doesn’t share them can cause a fair amount of frustration for the rest of the team and frustration is what needs to be avoided at any price as there is nothing that kills productivity faster.

Skills

In ideal world every team would have only senior members that are highly skilled and experienced. In real life this never happens and to be honest I don’t see any problem with having junior members on a team as long as they want to learn,  are capable of learning quick and there are not too many of them. If I had to pick I would say 1 junior for every 3 to 5 senior members is more or less the right ratio.

Software development is complex and it’s unreasonable to expect software engineers to be experts in every possible technical area. That’s why I believe every team needs to have at least one expert for each significant horizontal/cross cutting concern. Such a person would ensure consistency and correctness across all vertical features. One person can drive multiple horizontals. Sample horizontals: CSS, deployment, messaging, etc..

At the same time all team members, including experts, should work on vertical end to end features and ask experts for help when they struggle with a certain horizontal concern. In this way knowledge related to horizontals flows from experts to the rest of the team. On top of that every team member can influence a horizontal with experience he’s gained working on vertical features.

This approach takes initially more time than splitting the team by skills and let people work in isolation on what they know best. But there are a few very valuable advantages of this approach in the long run. Team is more resilient to departures because knowledge is shared and the quality of the final product is higher because the product is created based on feedback from both horizontals and verticals. Obviously, there are certain specialized areas of software engineering which might not work with this approach but it should be just fine for most of us.

Leadership

I’ve worked on a few projects where there was no team leader and this always lead to the same problem. Different team members had different visions of what we were trying to achieve and how we were supposed to achieve it. I know this might be a slippery slope and be against some of Agile principles but at this stage of my career I believe that every team should have a team leader to make sure everybody is going in the same direction and that the team avoids basic/fatal mistakes.

A good team leader is experienced, trusts other team members, treats them as partners, listens to them and always is more than happy to answer their questions but at the same time should be able to make the final call when it’s needed. And no, I’m not trying to promote absolute dictatorship as way of leading teams :).

Process

A healthy team is a team that is as independent as possible and is not hindered by the process it needs to follow. On top of that the team members should be able to use tools that make them most productive and they should feel that they are in the driver’s seat.

Size

I believe that a healthy team is a small team. Ideally 5 to 7 people but no more than 10. More than that and communication becomes challenging which slows down knowledge sharing and increases frustration.

Update: I've been asked a few times if 5-7 is the initial size of the team. The short answer is no. Ideally 2-3 people form the initial team and then bring more people when they are needed and team is ready to accommodate them. I didn't write 1-3 on purpose because I think that it's always good to have someone that you can bounce your ideas off.

 

The order of paragraphs matters but all of them deal with important issues and I wouldn’t ignore any of them lightly.

The blog post has been updated on 24/01/2012 with comments about the initial size of the team.

Tags: Software

Two talks of Joel Spolsky in Dublin

Both of them took place on November 7th. The first one was in the morning and Joel Spolsky was presenting FogBugz. Explaining the product on feature by feature basis Joel managed to tell the audience a little bit about how he thinks the software development process should look like. And you know that people like him are right in 99% of cases and you can follow them blindly ;).
FogBugz is a great piece of software that provides many desired by every software house functionalities like bug tracking, project tracking, Wiki, discussion groups, evidence-based scheduling and even a small help desk system. All these features are seamlessly integrated together in a way that the user is not aware when he/she moves from one part of the system to the other. Every activity that requires user attention is as simple as possible and what is very important as natural as possible. It's enough to say that whenever you need to specify an end date you can simply type word "week" and the system will calculate the date based on the current date. Adding new tasks to your to-do list is simpler then firing notepad (actually I do this every morning to keep my 5 most important task always in front of me). When you start working on a task you just hit start button and when you are finished you hit stop. The system calculates everything for you taking into account lunch break, scheduled meetings, your working hours, etc.  Those are small things but they show how the whole application has been build. Basically, FogBugz tries to be as transparent as possible to let you focus on your real tasks.
The next thing that impressed me a lot was the evidence-based scheduling. If you work with FogBugz you will never get just the end date of your project. Instead, you will get a set of dates and probability assigned to every of them. Taking into account how many IT projects are completed on time and on budget then this must be a better approach than what we have now. Needles to say that it does make sense especially when you take into account Quantum Physics.
The second presentation was part of the IJTC launch and Joe was talking about a topic that is as incomprehensible to software developers as the fact that they should not spend half of their life in front of a computer :). He explained how Companies take advantage of misattribution to sell us more of their products. His example was based on comparison of iPhone and a phone X of company Y. It's X and Y because I don't remember their names which is the best evidence that misattribution works :). Basically iPhone has fewer features, it's not extensible for the time being, it doesn't have a replaceable battery, it's 4 times more expensive and the features that are present in both phones are better implemented in the phone X. Why Apple has sold millions of iPhones and the company Y can only dream of something like that? iPhone looks way better and it's much more user friendly. People then attach the UI experience to the rest of it and that's how iPhone as the whole seems to be perfect in their minds. That's what Joel calls misattribution. Although I suppose that the marketing success of iPhone is a little bit more complicated beast I still think that his point is valid and it was certainly refreshing to me.

What kind of software development have you experienced?

Scott Berkun published his list of unofficial software methodologies :). Regarding these mentioned by him I've experienced: ADD, CDD, CYAE . Don't forget to check comments, especially: NMP, CPM and NIH.