Tom Breur
9 April 2017
Quality code is something everyone who has been a developer
can appreciate. It just looks better!
But more importantly, good and readable code dramatically reduces the time and
effort to update it. Since the majority of IT budget is spent maintaining code,
you would imagine good code is what everyone strives for. But all too often, I
hear “time pressure” as the overriding concern for not writing good code. This
seems odd, since it feeds a vicious feedback loop: we don’t have time, write
less maintainable code, making changes becomes more time consuming, and we wind
up with even less time!
So how do you break out of this gridlock? Developers are
smart people, they are aware of this dynamic. And if you are anything like me,
I still feel embarrassment and guilt over some of the poor programs I have
handed off. There has to be a better way. Since “I don’t have time for that” is
such a poor and invalid excuse, then how do you “justify” writing better code?
How can you do a more responsible job testing (yourself!), before you hand off
code to colleagues?
First of all, unless you genuinely take pride in your work, you
probably lack motivation to go through the hassle. Driving change can be hard
and challenging, like swimming upstream, even if it is for a good cause. Why
bother refactoring, cleaning up your development directory, if “good enough for
government work” is your standard? But if becoming good at automating tests (to
take a random example) requires time and a learning curve, you have to go through the pain of temporary
slower throughput. You have to get worse, first, before you are going to get
any better. It’s like that with many things in life. As you approach a task in new ways –even if they are better ways– you need to allow yourself
this intermediate degradation. And then
work through that, until you get better at it!
Never stop making the case for quality code. Unless you are willing to explain how this will
drive down TCO,
then who will? Reiterate how detrimental technical debt is to your
(sustainable) development pace. Give examples of the risks it may bring, and
try to express those in financial terms – the language that is best understood
by managers in just about every organization. And continue to hone your skills.
Build your craftsmanship, and deliver the kind of code you want to be
remembered for…
Tom i agree with you on how essential it is to drive productivity by writing efficient codes which we say good design.
ReplyDeleteGood code design is also dependent on requirement understanding, business understanding as this help in designing codes which we can re-sue and less trouble in scaling it to the next level as we already aniticapted what next we need to work on and we have accounted for that in our current design, proper planning is another important factor for writing good code.
Sharing of best practices are also essential to get it right without having multiple iterations. Testing is another factor which you have rightly touched is a very crucial factor.
These are common wrong practices which are growing in the organizations where development team and support team are 2 different teams as nobody wants to own it and they are happy to transfer the wrong doings to other teams. If we some how start merging these 2 teams and let them share the accountabilities this might be minimized but still can't be eliminated as you rightly said we lack motivation and we don't take Pride in what we are doing.
What is your scientific way and your objective means to measure "code quality" ? I have a little joke about that. I contend that all programmers in the world are in full agreement over what is the "best" way to write/organize code. When you ask that question to any one of them, they'll invariably answer "My way".
ReplyDelete