The Pragmatic Craftsman
:: Simplicity from complexity ::
The Pragmatic Craftsman
:: Simplicity from complexity ::
As programmers, we want to finish things fast. We want to impress our boss. We want to be better and always finish before others.
So we do. We finish things as fast as possible. Because the requirement was to complete the things that were on the list.
Just make it work.
What’s the end result? Code that is hard to read by others. Code that is rigid. Code that is fragile. Code that is over complicated. Basically, code that has the characteristic of “fast food” — it does what is supposed to, right?
Wouldn’t things be different if one of the requirements was “high quality.”
The statement is ambiguous. Sure. It means different things to different people. It could be more specific: “code should be easy to read, easy to extend, and easy to modify.”
High Quality. Enough said.
You could argue what quality really means. That’s not the point. Just stating that it has to be of high quality puts everyone on the same page: it communicates the expectation to the team.
“Why don’t we just add a special exception here.” No, you would say. That’s going to lower the quality of the code. That’s going to make the code more fragile and harder to extend. It does not meet the quality requirement.
I personally don’t need to be told that — quality is always on my list. I always try to make the code that I write be of high quality. I put focus on that. I don’t always get the results I want, especially after I look at my code after a period of time. But I learn. I improve.
There is just too much of low-quality code around. Too much pressure to finish fast and no pressure on quality.
Having quality a requirement would make a huge difference. I strongly believe that.
Even if your manager does not require it, “High Quality” should be one of the most important requirements when you write code. It’s not easy to write high quality code. That’s for sure. You learn with experience, by trying things out. Patterns develop after a while. Then you study a bit more. But having that focus we’ll make you a better coder and distinguish you from the others.
Related
Code quality and the fat developer, very good post by Consulting jiujitsu
Uncle Bob wrote an excellent post, Speed Kills. Is there a tradeoff between speed and quality, he asks.
If by “speed” you mean delivering working softwarequickly and repeatably release after release after release; thenmaintaining high quality is your only option.
I couldn’t agree more. In the long run, the only way you can move fast at high speed is if you have quality. Time and time again, I come across projects that were finished fast, with the thinking that they will never be modified again. (I’m not even sure if that’s always the case, but rather that quality was not a requirement.) After a few months, things change. They often do. And the project needs to be modified. What is your speed then?
It would actually make more sense to rewrite the project. But that’s almost impossible. Too many dependencies. Too much coupling. Who can read that and understand? Too risky. At that point, the easiest thing is to do is just add a special exception, an “if” statement that would make the thing work.
And the project quality degrades.
And the speed decreases.
Frustrating? You bet. Especially if you are not the original coder.
Wouldn’t it be easier if it was written with quality in mind in the first place?
Reference
Speed Kills by Uncle Bob
I just read an overview of the Java EE 6 release. It looks like Java EE is becoming simpler, smaller, and less configuration hungry. Glad to that.
Few things that sound exciting to me: WebBeans, Profiles, JPA 2, JSF 2.
It’s probably a year or so away. I wish the process moved a bit faster.
Reference
Java EE 6 Overview
Related
On a related note, this article puts this direction into perspective, Towards Java EE Nirvana
