Weeding out the weak

Following up from Jeff Artwood’s recent post, Programming: Love It or Leave It I thought I would share some of my recent experiences and some thoughts on the topic.

Firstly, I completely agree with what Jeff is saying about there being too many people in the software industry because it is convenient or because they are out to make some quick money. A large number of people are simply never going to be more than average developers and they do not really have a strong passion for what they are doing. They are the nine to fivers that give only what is required (or less) and are never trying to move forward or improve things.

The passion for development
Having recently been made redundant along with Christian Biggins and numerous other co-workers, a few points have come to mind. It is quite sad that in the recent “cost cutting” exercise it was predominantly the more skilled and experienced developers that were dumped while what is left of the team now consists (not entirely) of the nine to fivers mentioned above. Most of the people that were trying to improve quality and make changes for the better have been left wondering why they committed themselves so completely.

The other point that has become apparent to me is that myself and a few others are indeed the type of developers that will not simply give up on software development because of the situation or the “economic downturn” or any other reason. Several of us have launched new projects (including Fliquid Studios) and spent even more time developing now than when we were officially employed to do so. I intend to keep developing, giving what I can back to the community and in turn learn new skills for myself. I honestly have a passion for web application development that will not go away.

The problem with the industry
I believe that the problem is not that there are too many developers or developers without a true passion for what they do. Instead, I am suggesting the problem is that for too long our “clients” (be they our employees, third party customers or otherwise) and indeed ourselves have been simply accepting sub-standard results.

The problem our clients face is that it is not always easy to determine whether software is poor quality or not without some kind of technical insight. It is far too easy for a developer to make an application look nice while underneath it is a steaming pile of…. less than good quality code.

Rather than waiting for the “bubble” to burst to weed out the developers without true desire to be in the industry I suggest we try to change things so they either improve what they are producing or make a conscious decision that software development is not for them.

What can we do?
If our clients are unable to ensure the quality of what is being delivered then it is up to us, as passionate software developers, to continually push for higher quality and improved standards. By continually increasing the standards and showing the kind of high quality, reduced-bug, innovative software that can be delivered, sub-standard developers will be forced to improve what they are producing or move on.

I’ve included a few initial ideas below to get the discussion started on this topic but what I am suggesting is just the beginning.

  1. Implement coding standards in your organisation (for example PHP, SQL standards etc) for code formatting and documentation. Whether this is your own standard or the use of an existing one such as the Zend Coding Standards. You must also ensure that developers are familiar with and understand the reason for the standards.
  2. Code reviews – If code reviews aren’t being performed by senior developers in your organisation this is a great way to “catch” problems in software or the lack of good quality code before it’s too late.
  3. Open Source your software (or parts of it at least) – Feedback and improvements from other developers with a different perspective can be a great way to improve quality and detect otherwise undiscovered problems in code. It also gives something back to the community.
  4. Be proactive – Put forward new ideas as often as your can. Try implementing small improvements. Encourage an open forum for ideas. This kind of proactive ideas driven development helps with innovation and moving forwards.
  5. Implement automated testing (however this is appropriate) for your application and enforce that everything passes

Conclusions
The IT industry is full of low standard results. We should be proactive in trying to improve things rather than waiting for the bubble to burst. There are numerous ways we can kick off this process to start towards a future of high quality software and we, as developers have the knowledge to make a difference.

As always I would love to hear your thoughts and feedback on this article. Am I a raving lunatic or do I make some sort of sense? This article is intended to open up discussion on various methods we can use to improve software as a whole so please feel free to contact me with any of your thoughts.

December 30th, 2008 | tags: , , , , | Other posts by Michael Little
  • You make a good point Bobby. I agree, we should always be pushing for higher quality. Thanks.
  • Bobby
    I only skimmed the post, but I disagree with your assessment of the problem with the industry.

    "If our clients are unable to ensure the quality of what is being delivered then it is up to us, as passionate software developers, to continually push for higher quality and improved standards."

    I think this is exactly backwards. We should be pushing for higher quality and improved standards anyway.. It's not our customer's responsibility to make sure we don't write crappy code, it's ours. Clients calling us out on bad code should be a last resort and the exception to the rule, not as what you require in order to start writing good code.

    I think your proposed solution goes on to address the real problem, but for the wrong reasons.
  • Thank to you all for your comments.

    Andrew, you make a very good comment. I agree completely with most of what you are saying. I have actually read quite a bit of Martin Fowler's literature. Speaking for myself though, I generally find it easier and faster to write clean, structured, reusable code whether it is for throw away purposes or long term use. I guess this is just force of habit.

    I'd just like to clear up about the reasons behind the people who were "selected" for the redundancies. The reason certain people were selected was merely a case of wrong place and wrong time. It was nothing we had done wrong or that we achieved less results than others. On the contrary several of us were frequently noted as "outperforming" some of the developers that retained their jobs. The point I was trying to make relating to this in my post is that performance, skill level, length of service or any other factor did not play a role in selecting who kept their job and who did not.

    Thanks again.
  • Programming is really a means, and not an ends. Generally, companies aims to make a profit, and to put themselves in a position to make profits in the future, and so ultimately, how good code is should be measured by how well it meets those objectives. Conscientious individuals want more than just profits - they often want to make the world a better place as well, and so this opens up a whole lot of other objectives which people can optimise for.

    However, writing elegant, or reusable, or well formatted code generally does not help the achievement of the goals in the short term; getting users the features that help them when they want them (and which work properly) helps optimise the objective function.

    In the long term, kludgy code can be harder to maintain. Martin Fowler's writings on 'technical debt' ( http://martinfowler.com/bliki/TechnicalDebt.html ) are a good way of looking at this. If code is for research or prototyping or other throwaway purposes, and it is unlikely that anything being written can be used later, then it doesn't matter if you write incredibly kludgy code - the best thing is to churn out code as fast and as cheaply as possible. The same level of unit testing used for reusable code might also be a waste of time - there is no point testing a non-reusable routine for parameter values outside the domain which it will ever see.

    On the other hand, if code is going to be maintained for years, and parts of the code are likely to be useful in house for other purposes, you don't want to get into technical debt, and should spend the time to write elegant and reusable code, written to make things easy to extend later, and easier on maintenance programmers.

    In short, good programming is really about long-term pragmatism - always about making sensible trade-offs between short-term pragmatism and excessive idealism. It may be that the 9-5ers who kept their jobs were actually making this trade-off better. Then again, maybe management mistook the productivity achieved by short-term pragmatism and will pay for keeping on the wrong developers later when the technical debt starts to pile up.
  • A real nice post. Agree that a prolong exposure to sub-standard code has really made people accept that, this is what real coding is :-( Infact, most of the so called Developers in todays IT industry can't even write decent code, leave out innovation. Rare the passionate developers and if they are they become so overloaded to ensure Quality that they can hardly breath. Also agree with Mark that, Management is fine as long as things as working. To satisfy hunger to improve myself, made me work in Open Source projects, learning from real passionate Developers.
    As far as your opinion on "What we can do", I tend to disagree that its going to be of much help. Empires of Knowledge are build on knowledge, you really can't make a person write good code by following conventions. Its just uniform.

    Still, we ought not loose the faith. There are plenty of our kind around. So lets contribute whatever we can.
  • Mark
    The problem is that management will never (ok, a few will) value people like us. I truly believe that you have been forced to make the correct option - You have to create your own company. It will be a tough sell. You need to find the same committed people to partner with, including sales and marketing people. Be cautious of who you choose and don't be afraid to cut loose those who don't show the same commitment. There are plenty of 9-5 jobs for them.
  • "The good thing is you’ll probably get better recognition if you aim for higher standards and are vocal about it."

    I guess thats it, isn't it? I mean, if all developers were fantastic, then there would be no margin between good and great developers. None of us would receive the deserved recognition for being better than the others.
  • "Am I a raving lunatic or do I make some sort of sense?"
    Probably both. While I applaud the initiative, and wish there was less bad code around here, I believe there is hundreds more 9-5ers than there is passionate developers. This makes improving things a lot harder. The problem is especially noticeable when the barrier of entry is very low, like with PHP and most other interpreted languages.

    The good thing is you'll probably get better recognition if you aim for higher standards and are vocal about it.
blog comments powered by Disqus