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.
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.
you have some very good points here. If I got you right you see craftsmen as the “artists” like jewelers. But there are different craftsmen: plumbers, carpenters etc. They do have contact to customers. Part of their job is to find out what the customer needs. Do you consider that service work?
I think it is more a mentality than a job classification.
Lets say that the water heater is broken and I run out of hot water on occasion.
A plumber that goes in with goal of installing water heaters would be more of a craftsman. A plumber who comes in and looks at the problem ends up dusting off a sensor and increases the temperature of the boiler to help with the occasional lack of hot water is more of a service provider. Both give me what I want, both get a result I like. But one considers the cost to me and the other doesn’t.
There is a lot of experience in buying plumbing services, and if you had a plumber come in and spends 5 min on a water heater prior to offering to install a new water heater will get shown the door and you get at least a second opinion. That is because we have expectations when it comes to buying plumbing services; chances are that either we have bought some ourselves, our parents probably bought some, our neighbors and likely the guy sitting next to you at work as well.
This in turn means that plumbers who do not take a customer centric approach either gravitates to new construction/renovation work or go out of business.
The end result is that most plumbers are service providers because they know that a happy customer is the most important thing to leave after they are done. More important than a working water heater even, because a happy customer will call again & refer you to others and that is how they stay in business.
But I’m sure some are not.