“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.

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.

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.

Still, we ought not loose the faith. There are plenty of our kind around. So lets contribute whatever we can.

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.

The good thing is you’ll probably get better recognition if you aim for higher standards and are vocal about it.