People have always had the most interesting problem of what developers are.

One of the first attempts I know of has been the Mythical Man-Month, it communicated the concept that some developers had 10 times the output of other developers. Ten times the output is completely unheard of in manufacturing, really in most of the engineering fields. This idea spawned the idea that some developers must be artist, since that is an area there the 10 to one ration makes great sense. There are after all many artists, and we only hear of a few, there are the greats and the rest.

The artist concept is interesting but completely unmanageable for an industry.

• How can you price a developer who is ten times the value of an average developer?
• What would you do when the developers catch on?
• How can you replace these types of developers ?

Industry is there to make things, so the search was on for a way to make developers.

So we move on to the Pragmatic Programmer, and the introduction of the craftsman. Craftsmen seems much more manageable, craftsmen can be trained. The concept that there is a core body of knowledge and any person who masters it becomes a developer. Sure talent is in there somewhere but the important thing is the technologies. Software engineering was born, organizations sprang up, acronyms were created, levels defined and a bright new path was set that allowed organizations to tame their software problems.

That seems to be where we are at these days; Developers are craftsmen who care about honing their trade to perfection. If you want better results adopt these technologies and it will happen; and if it fails then you probably didn’t implement enough or did it wrong. Go to a presentation on Agile, Scrum, or some other methodology and they will all tell you that the only people that they knew that abandoned the technology were those that didn’t implement it right. The good news is that the guy presenting is probably a consultant who can help you implement them right.

And this idea is convenient for the developers as well, it gives them this nostalgic concept of being the creators. Part of a profession in the making, there are organizations springing up to certify developers. The rules are just being created and developers are eager for certifications and titles, for all that aspire want to one day be called the architect.

It seems that the craftsmen metaphor is working, and the development industry is rapidly shaping itself to fit it’s new mold.

Although there are some gaps for starters engineering disciplines are very rarely in a position where measurements are a massive problem. Like how do you measure the output of a developer, how do you predict the output of an architecture, how do you quantify the difference between two architectures. Sure we can call this part of being a new discipline but it goes a little bit deeper. And that is weird, everything we create is already in a format that is friendly for measurements, it is even discrete.

But measuring fails. We can measure lines of code, but keeping all else equal we prefer less to more. Less is easier to comprehend, easier to maintain, likely faster to write, likely less buggy and in the end cheaper. That is why we use higher level languages, abstractions, code generation and most other popular techniques. The same goes for features, more buttons does not make an application more valuable.

Another issue comes from the inherit problem of the craftsmen concept. It goes as follows. Envision a craftsman. What is he/she doing?

They are probably making something.

And that is the problem. If you ask a craftsman for something their response is to make something. The question rarely matters much as the craftsmen focus on it as an opportunity to make something. And quite often this creates the problem. No one is complaining that developers are not creating things, but they are complaining that they are creating the wrong thing.

It is the beautiful monster that was created when the developers all got convinced that they were craftsmen and started to act accordingly. They are creators, and the creation is done because that is what defines them. They learn how to create more, better, faster and sometimes closer to the right thing. After all, if it was wrong it was probably bad requirements.

Requirements are funny, it is like an insurance policy against being wrong. We have some poor bastards write it out before hand and then the developers have a shield to hide behind. Sure some methodologies are trying to get the requirements out of the picture, or at least more flexible. But this is still done under the guise of being craftsmen and creating a more perfect creation. And that is why it doesn’t work all that well.

As long as developers are considered craftsmen the most important element of software development will stay in the background.

The customer.

That is because craftsmen and customers don’t traditionally meet. It is the sales people that are the bridge. The craftsmen create, and the sales people find those who’s needs the product meets.

In software this is not really as easy, for consumer software there is a lot more competition, and for industry software there is often only one customer. So for success to be possible the product has to suit the customers quite closely, and then the sales people can do the rest.

To bridge this gap there is the introduction of the BA; and that would be the poor bastards that get to play the telephone game between the developers and the customers in a desperate attempt to make the product suit the customer. They get to be the glue between customers and development. And as long as they are there developers won’t have to take ownership in front of a customer.

But let’s imagine what would happen if tomorrow all BA’s get fired (no, I don’t hate all BA’s)

The only way that companies would be successful is if the developers start talking to the customers, and that the developers become responsive to the customers’ needs.

The only way that organizations will survive is for developers to become service sector workers.

Oh, and when we assume that developers are service sector workers measuring becomes pretty easy. I’m pretty sure everyone has filled out some sort of customer satisfaction survey before and that seems to be working pretty well for the industry.