Does everyone need to be the one that chooses?

Listen with webReader
Published 13 October 09 01:45 PM | wmmihaa

Johan Lindfors and Patrik Löwendahl did a duoblog titled “Everybody wants choices but nobody wants to make a choice” where they wrote about the growing opinion that software development and .net framework is getting to complex. It was later commented by Johan Hedberg among others.

It’s a very relevant issue, as many of us struggle to convince other developers and organizations to embrace new technology. But even though I agree with most of what’s been said, there is one part I strongly disagree with:

Patrik Löwendahl wrote:

“..developers seem to not understand the basics of the job requirements. As a software developer, my job always include constant learning and constant improvement of my skills. If I can’t agree with that I am a bad developer. This is not the tool vendors fault, this is because business change, improve and learn as well. If we don’t do that with them, we will be left behind.”

Only a tiny fraction of the worlds software is currently being built, some is being re-factored but the overwhelming majority is in “maintenance mode”. Of course this allocation is also reflected among developers, as many are working with already existing applications, adding new features, fixing bugs etc.

Naturally, these developers grow more focus and understanding of business requirements rather than the evolvement of the underlying technique. This is only natural as transition from already established standards such as Visual Source Safe, ODBC and ASMX, will not be prioritized in comparison with new features and capabilities of an already working system.  

One could argue that if they don’t keep up with the latest technology, their system will eventually become unmanageable. When key resources find better (and more interesting jobs), they will face a challenge finding anyone willing to take the job. But if this is the reason for adapting to the latest technology, it’s not the technology in it self they will benefit from, but the access to “good developers”.

As Johan pointed out, this is a problem for the management. –Sure there are bad developers, but focusing on the business needs and prioritizing your family and friends does not make you one!

If I’d call for the janitor to come and help me with a problem in my apartment, I’d rather see the a person with years of experience from my building than an outsider with a cool tool belt. The knowledge about every pipe in the building, will impress me more then the DeWalt DC927KLV in his hand.

Everyone who knows me, knows that the last comment is a lie. I would drool over the DC927, in fact begging to try it out. But the point is, my passion for technology (and power tools), does not necessary make me a good developer, for the same reason the employee with a deep understanding of the business is not necessary a “bad developer”.

It’s all about being the right person for the job, eager to solve the business need. Sometimes, and especially in new projects, the passionate developer is essential to make life easier for the ones making sure it will evolve with the change of the business. 

Filed under:


# Patrik Löwendahl said on October 13, 2009 02:29 PM:

Interesting viewpoints Mikael and very valid once,

I must say though that I don't agree with everything you say. To begin with, I don't argue that you should choose technology over your family. There is nothing implicit in "keeping up to date" that makes you use your spare time.

This is an organizational issue and have an effect on the core issue that we discuss in our posts but is far from the real issue: People just don't WANT options, they don't want to go outside their comfort zone and find better options. They don't care if new technology saves their clients money or makes them faster in delivering business value, they want what they've always had and that is good enough.

This is the definition of a bad developer, maybe a good maintainer but not a good developer. Developers develop their clients business in not only features but in process, development methodology and so forth. Every improvement to the business counts when the balance is calculated.

So a good developer knows when there is a better option, they understand what will bring the best value to the client with the most efficient tools and methodology for the task. Someone that don't understand this, is a bad developer.

Also on the note of maintenance, Michal Feathers (author of Working with legacy code) talked on NDC about upgrading your tools and frameworks continuously to not fall in a legacy trap, listen here (

# Johan Lindfors said on October 14, 2009 10:16 PM:

Very interesting and valid points, both of you! I hope these discussions continue to evolve and that the overall community gets involved, both passionate and pragmatic/practical.

# Mike Stephenson said on December 20, 2009 08:50 PM:

Hi All,

Interesting discussion point here, but i think one important angle is the team dynamic.  Its great to have lots of people like described above but you also need other personality types.  Usually people who are really driven by latest technologies etc are not "finishers".  

You need those people who just follow the teams practices and get the job done and they can be every bit as important as the guy gets the team moved to the latest .net version or using the cool new widget.

Its all about the team, and hopefully you have a few pragmatic people around who can maintain the balance.

# wmmihaa said on December 21, 2009 10:26 AM:

Thanks Mike,

I totaly agree, in fact, that was the point I was trying to get through.

# Johan Åhlén said on September 19, 2010 12:50 PM:

There was a discussion about a year ago on Swedish blogs about why developers don't adopt new methods

This Blog


    MVP - Microsoft Most Valuable Professional BizTalk User Group Sweden BizTalk blogdoc

    Follow me on Twitter Meet me at TechEd


    Locations of visitors to this page


    The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.