Innovation can't be planned

The profession of software developer is a relative young one. As such we learn new things about it that other professions already have figured out. This post is about one of those things that managers who need to manage developers rarely seem to get: innovation.

Software development is devided in two different types of work, the standard projects for which you can simply apply well known en documented methods that lead to a predictable result, and the innovative projects where features and requirements can change based on the technical possibilities and impossibilities.

For example, implementing a corporate intranet in a CMS is well understood and tends to be predictable. On the other end, building a new product where the UI has to be available on a wide range of platforms and devices is not only new, but also has numerous variables that make it different every step along the way. Sure, there are methods to execute a project like that in a structured way.

Most agile methods appear to be suited to do highly innovative projects. However, they do have a single flaw, which I've recently experienced. Although they do allow for great flexibility in the big picture, once it comes down to the detailed work, they don't allow that same flexibility because at some point there still has to be some predictability so it can be sold to managers and executives alike.

In practice, when using an agile method, developers are still required to commit to delivering a certain amount of work within a certain amount of time. The only thing that has changed is the amount of work they are asked to make an estimate for. It's like instead of asking to design and build a spacecraft you're now asking for only the propulsion system. Sure, it's less work, but it's still highly unpredictable, especially when you find out the maximum speed in the specification is not nearly enough to get the craft to the destination within a reasonable amount of time and the fuel consumption needs to be cut in half.

Obviously the example above is exaggerated, but the point is that with innovation things can only become apparent once you're working on it. You encounter problems you could not have thought of and you have to solve them in order to deliver a product that's up to standard.

So how do you go about building an innovative software product? The first thing is to make sure you have the right people leading the team and trust them. Also make sure there is a clear set of boundaries that the team needs to operate within. Then support them and facilitate their work as much as possible.

This doesn't mean you can not put a timeconstraint on a project. However if you do, you should be prepared to compensate for that in functionality (some would argue that you can also assign more resources to a project, but why I think that has great limitations is a topic for another post).
So please, stop trying to plan your innovative development as you will only be disappointed.

Writing code != developing software

There has been some fuzz online about whether or not should everybody learn how to write code. In this post I’d like to add my point of view and take into account what the profession of developer involves (or should involve).

If you have not followed this discussion, you might want to read up on some other posts firsts:

Please Don't Learn To Code - Jeff Atwood

Please Learn To Think About Abstractions - Scott Hanselman

In a nutshell the fuzz is caused by public figures announcing they are going to learn how to write code.

The car mechanic

There has been several comparisons with other professionals already. However I think they are not really suited for what is happening here. I like to explain why learning how to write code doesn’t mean anything by projecting this to the profession of the car mechanic.

Let’s say I announce I’m going to learn how to work on an old car engine. If you analyze the skills I need to work on a car engine it almost becomes laughable:

• I need to be able to open the bonnet of the car
• I need a basic understanding of tools in the toolbox (a spanner, a screwdriver, etc.)
• I need to be able to start the car and drive it in order to test my work

Anyone can see that it I work on a car engine with only the above skills, I’m very likely to ruin the engine. At the very least we can conclude that being able to work on an old car engine doesn’t make me a car mechanic.

Let’s project this example back to the software developers profession. If you want to write code you need the following skills:

• I need to be able to install and run an IDE
• I need to be able to type code in the syntax for the language I’m using
• I need to be able to use the IDE to compile and/or run my code

If you are going to use only the above skills to write a program, changes are you are not going to achieve the results you want. In any case the above skills are not nearly enough to become a software developer.

The software developers profession

Jeff Atwood makes an excellent point in his post when he states that being a software developer is not about writing code, but about solving problems. I completely agree with Jeff on this point. If you read the post he refers to when making this point (here), you’ll see he paints a very bleak picture about developers being extremely disconnected from the users they are building software for. I personally do not have that experience, but then I’ve always worked in relatively small teams (six developers being the max).

In my career I’ve coached several developers and I’ve always been an advocate of what to me is the single most important skill any developer should have is the analytical skill. I’ve even given short trainings in analysis. When another developer asks for my help solving some problem, I always try to be very verbose on how I get to my analysis.

And as Jeff Atwood also states in his post, writing less code is better. In order to do that, being analytical about what you’re trying to achieve is crucial.

Obviously you can have all the analytical ability in the world, but if you don’t have a proper understanding about what you’re dealing with, it being the inner workings of an operating system, or the politics around some customers feature request, you can not make a proper analysis. This means you do need knowledge.

This brings me to a problem that is fairly unique to the software developers profession. Code is not knowledge, however it is transferred and documented online in vast quantities. This has created a whole breed of so called developers who simply go online and copy code for what they think solves a particular problem they’re having, without actually understanding what the code does, nor why they are having a certain problem. The term Lamer comes to mind.

The danger with that is that someone who does that might think that they solved a problem, however they might very well have not. And because of the lack of understanding they are unable to verify if the code solves the problem, nor are they able to troubleshoot the code if needed.

The software developer needs to analyze the users problems, then come up with a solution that fits the users needs. Again it’s not about the code. It’s about the solution. It requires a deep understanding of computers and the users needs and it requires analytical skills and a creative mind to come up with a fitting solution.

This is just my two cents. Please leave any comments, questions or rants below. I’d love to hear how others perceive this.