What if writing code would be like writing a novel?

On the field of analogies here is one that is quite well presented: Writing code is like writing a novel.

Check it out at Kevin Barnes' blog.

Analogies are only useful if they give insights on the activities you are studying, like coding as part of software development in my case. This one is simple but full of insights.

Software development as film making

And to prove that I'm not original :), here is a post where the analogy between software development and film making is made.

Old-school methodologies grow until they become the proper goal of the software development process.When an old-school methodology is created, a set of rules come into existence. Those rules are believed to make the software development process successful as promised by: Professors, Consultants, MBA's, etc.Since those methodologies come with such a high recommendation they obviously become the focus of management (especially if there are Professors, ex-Consultants or MBA's in that management). Having become the focus of management, the methodology will then be mandated to the whole organization, and it will be enforced by the "methodology-police" which is often consituted by those layers in the organizational-pyramid whose jobs depend on the importance of the methodology.The people that are normally most committed to the methodology are those that are promoted to positions where they perceive having more power, power which normally comes with the following attached: "You have power to enforce this methodology. We trust you to do that and to prove that we will give you bonuses based on how your people follow the methodology". These are also the members of the "methodology-police".Once this scenario is set the real problems start. These old-school methodologies often require developers and testers to produce certain things that are not software (often called artifacts or intermidiate deliverables). These artifacts are required because the methodology-police believes that they will ensure project success per se which, of course, is many times not the case...All these artifacts bring waste to the development process, but they are still seen as a stepladder to success. Also, the fact is that the methodology-police often has a very weak link to the actual running software: they just "manage" people that do have a direct link to the software, or worse yet, they only enforce the methodology. This often leads to an artifact-led software development process, as oposed to a "running software"-led development process.Help on the way?Agile methodologies with their emphasis on "Running software" reduce the need for those artifacts, for the complexity of the methodology and in turn reduces the need for the "methodology-police". Don't get me wrong, you still need coordination (lead developer, lead tester, scrum master/agile project manager), but that coordination only exists with the goal of facilitating the most important role of the software development process: "writing working code that solves a problem for the customers/users".The conclusion is that Old-school methodologies for software development cannot be as productive as Agile methodologies because they require more waste.You may ask: but we have big teams, in many places they surely need some structure (read old-school methodologies and methodology-police).Yes, they do, but that's why you should - if at all possible - have small super-productive teams that can deliver software!Ther are other obstacles to having small teams deliver software that is very complex, but all can be surpassed. The question is: who will do it first? You or your competitor? You decide... Posted by

Old-school methodologies grow until they become the proper goal of the software development process.

When an old-school methodology is created, a set of rules come into existence. Those rules are believed to make the software development process successful as promised by: Professors, Consultants, MBA's, etc.
Since those methodologies come with such a high recommendation they obviously become the focus of management (especially if there are Professors, ex-Consultants or MBA's in that management). Having become the focus of management, the methodology will then be mandated to the whole organization, and it will be enforced by the "methodology-police" which is often consituted by those layers in the organizational-pyramid whose jobs depend on the importance of the methodology.

The people that are normally most committed to the methodology are those that are promoted to positions where they perceive having more power, power which normally comes with the following attached: "You have power to enforce this methodology. We trust you to do that and to prove that we will give you bonuses based on how your people follow the methodology". These are also the members of the "methodology-police".

Once this scenario is set the real problems start. These old-school methodologies often require developers and testers to produce certain things that are not software (often called artifacts or intermidiate deliverables). These artifacts are required because the methodology-police believes that they will ensure project success per se which, of course, is many times not the case...

All these artifacts bring waste to the development process, but they are still seen as a stepladder to success. Also, the fact is that the methodology-police often has a very weak link to the actual running software: they just "manage" people that do have a direct link to the software, or worse yet, they only enforce the methodology. This often leads to an artifact-led software development process, as oposed to a "running software"-led development process.

Help on the way?

Agile methodologies with their emphasis on "Running software" reduce the need for those artifacts, for the complexity of the methodology and in turn reduces the need for the "methodology-police". Don't get me wrong, you still need coordination (lead developer, lead tester, scrum master/agile project manager), but that coordination only exists with the goal of facilitating the most important role of the software development process: "writing working code that solves a problem for the customers/users".

The conclusion is that Old-school methodologies for software development cannot be as productive as Agile methodologies because they require more waste.

You may ask: but we have big teams, in many places they surely need some structure (read old-school methodologies and methodology-police).

Yes, they do, but that's why you should - if at all possible - have small super-productive teams that can deliver software!

Ther are other obstacles to having small teams deliver software that is very complex, but all can be surpassed. The question is: who will do it first? You or your competitor? You decide...

The uncertainty principle in software development

While surfing the web I came across this post from Kevin Barnes.

It's hilarious! Great insights can be easily conveyed through humour! :)

From now on you can use this to say: "You either have software requirements or the actual software, it's proven by scientists!"

Software development processes try to achieve the impossible: "repeatable success despite who implements them".How about this thought: Repeatability comes from people, not from processes. Why?Software development processes are procedural rules to follow when developing software. Let's, for the sake of argument, ignore the fact that those rules rarely focus on the actual work, but rather on the management of that work.Even if processes would be "perfect" definitions procedures to develop software, before they can be applied they have to be understood by a less than perfect mind. Project team members will read the process documentation, make their own assumptions, based on their own experience and on input from people they value and then proceed to implement their own flavor of a process.Even if you have a "perfect" software development process it is still true that people will do the actual process implementation, it is also trivially true that people are different, so the logical conclusion is that repeatability can only be achieved by maintaining the same people doing the same job.Consider the alternative: define a process so that there is only one, and only one way to understand and apply it. (Does this sound like "complete requirements"?, it probably is the same: a mirage crafted by people with little understanding of what software development really is).Having people at the center of a software development process is according to the Agile values (which value people and interactions over processes and tools), but it is completely against the old-school thought that people are and must be replaceable.The people issueHaving read many books on the issue of "managing people" I still believe that the best advice to people working in software development is: talk to your people, learn to know them, listen constantly and you will definitely become a better manager!If you do that and stick with your best people you will be given the "repeatable successes" you have so long be looking for.For some good reading on "managing people" take a look at these:First, Break all the rules; Marcus Buckingham et al; Simon & Schuster (Trade Division), 2001Peopleware: Productive Projects and Teams; Tom DeMarco et al.; Dorset House Publishing Co, 1999Maverick!; Ricardo Semler; Random House Business Books, 2001 Posted by

Software development processes try to achieve the impossible: "repeatable success despite who implements them".

How about this thought: Repeatability comes from people, not from processes. Why?

Software development processes are procedural rules to follow when developing software. Let's, for the sake of argument, ignore the fact that those rules rarely focus on the actual work, but rather on the management of that work.

Even if processes would be "perfect" definitions procedures to develop software, before they can be applied they have to be understood by a less than perfect mind. Project team members will read the process documentation, make their own assumptions, based on their own experience and on input from people they value and then proceed to implement their own flavor of a process.

Even if you have a "perfect" software development process it is still true that people will do the actual process implementation, it is also trivially true that people are different, so the logical conclusion is that repeatability can only be achieved by maintaining the same people doing the same job.

Consider the alternative: define a process so that there is only one, and only one way to understand and apply it. (Does this sound like "complete requirements"?, it probably is the same: a mirage crafted by people with little understanding of what software development really is).

Having people at the center of a software development process is according to the Agile values (which value people and interactions over processes and tools), but it is completely against the old-school thought that people are and must be replaceable.

The people issue

Having read many books on the issue of "managing people" I still believe that the best advice to people working in software development is: talk to your people, learn to know them, listen constantly and you will definitely become a better manager!

If you do that and stick with your best people you will be given the "repeatable successes" you have so long be looking for.

For some good reading on "managing people" take a look at these:

First, Break all the rules; Marcus Buckingham et al; Simon & Schuster (Trade Division), 2001
Peopleware: Productive Projects and Teams; Tom DeMarco et al.; Dorset House Publishing Co, 1999
Maverick!; Ricardo Semler; Random House Business Books, 2001

Is IBM changing ?

I never thought I'd see a post from IBM/Rational that stated that "more process" is not always a good thing. Especially since they have been pushing Rational Unified Process so strong.

But, here it is:
"Anti-patterns: Precise plans/estimates, track against static plan management style. More process is better. Always use the same degree of process throughout the life-cycle."

I especially like the part: "More process is better." (note that this is under anti-patterns! :)

The idea of adapting (as stated in the article linked) is nothing new of course, it had been advocated by many people and documented in a little known site located at www.agilemanifesto.org.

Much of what is stated in IBM's paper is pretty much common sense (which begs the question: why did it take them so long to get there...), but it is a good sign that the big blue is starting to see the light.

Microsoft a close second in the Agile race?

Microsoft also jumped on the Scrum/Agile bandwagon. Through David Treadwell MS stated: "

"Treadwell said many teams within Microsoft rely on Scrum as a way to turn out quality software on time and in tune with user requirements.

Yet, "one thing we find is that you can't excessively mandate software development processes on a broad scale," Treadwell said."

Wow. I don't know if the rest of the MS-organization really understands what that means, but the fact that David states it like that really gives me hope that the wisdom will start flowing to other companies in the industry.

One thing is sure, at least now I can even quote MS at work in defense of self-organized teams that define their own process with a view to achieve the best performance possible!

Here's to hoping.

Old-School development methodologies

The Software Development industry is in it's adolescence

The software industry is fairly young, the first Personal Computer together with the Operating System that made it wide-spread (MSDOS) was only available in 1981 [1].

Since then the industry has evolved very, very fast which allowed many "snake oil" sales men to take it over (I could name a few...). The explosive growth also allowed many people with low or no technical qualifications to enter the industry, including at the top-management level.

Without enough time to sediment learning and with a drive for quick-(empty)-profit (remember the IPO's of the late 90's?) the industry was then invaded by a horde of fresh MBA's that had no knowledge of what software development really is.

This, of course, led to a lot of failed companies a lot of grieving, but it also opened the doors for those in the industry that did understand the software development process.

People like the ones behind the Agile Manifesto (www.agilemanifesto.org) started making waves in the software development industry due to their success in leading and participating in software development projects.

Surely enough a huge discussion ensued about what is the "best" software development methodology (even within the Agile Manifesto original signatories). As luck would have it we humans learn better by analogy, so a war of analogies was inevitable. We heard of software development as house building (remember waterfall), as a "cooperative game of invention and communication" [Cockburn], we've also heard that waterfall is a bit like the famous middle-age practice of "blood-letting" [Larman]. Here's one more: software development is like making an animated movie.

Analogies are only useful if they allow us to gain some insight into the object of our study (software development in my case). Movie-making offers some important insights in the software development process, but I shall discuss those in another post, as this one is quickly becoming too large :)

Why, then do I use the "old-school" qualification?

Old-School software development methodologies are based on "old principles" that, even though they worked at some point (before we knew better) they are clearly outdated and are no longer effective.

Old-school software development methodologies are based on old organizational structures which follow heavily the pyramid organization of the Old Church (Catholic Church) and pre-Enlightenment days. The pyramidal organizations also follow closely the "command-and-control" principle, that's the basis behind the successful implementation of a Pyramidal organization.

Old-school software development methodologies tend to be taught in schools in the same way as education happened in pre-Enlightenment days: heavily based on theory, book reading and remembering, instead of practice and empirical analysis or real cases. This leads the students to believe in a system of values without ever understanding them or it's application deeply.

Old-school software development methodologies tend to rely on the old idea of scientific management [Taylor in Semler] in which someone can tell a developer how best to their job without actually doing it. Example: a Software Architect/Software Designer telling a programmer how the code should be written, even when they don't touch the code! To improve results with this technique try having the Software Architect in the United States and the Programmer in India :) (I don't mean with this that we don't need Software Architects, they are fundamental and their role will be discussed in another article)

Old-school software development methodologies follow the old Ford model of industrial production, as if programming could be equated with an assembly line. A basic problem with this approach is that not even cars are produced the same way anymore [Poppendieck]... Why should software? To best visualize what is meant by this paragraph please re-watch the Chaplin classic "Modern Times".

Old-school software development methodologies are also based on old management methods. These management methods advocate control by stating that no one in the lower ranks of the pyramid is really competent (otherwise they would be managers) so the top management must control the lower ranks with tight and rigid rules designed to make those in the lower layers more productive than they could be were they to be given freedom to organize their own work (God forbid).

So what methodologies am I referring to?

As you can easily understand I'm referring to all methodologies that, like waterfall, follow the set of values described above.

All methodologies follow a set of values that define them and how they will be understood and applied. I use the term "Old-school software development methodologies" to easily label all methodologies that are based on the set of values described above and in contrast with Agile Software Development Methodologies which follow a different set of values.


Like this post? Let others know: Digg it!

References:
[Cockburn], Alistair Cockburn, Agile Software Development, Addison-Wesley, 2002
[Taylor in Semler], discussion about tailorism in Ricardo Semler, Arrow Books, Maverick!, 1993
[Larman], Craig Larman, Agile and Iterative development, a Manager's guide, Addison Wesley, 2003
[Poppendieck], Mary Poppendieck et al., Lean Software Development: An Agile Toolkit, Addison Wesley, 2003