A nugget from Uncle Bob's Clean Code.
Computer programs should be in such a way that it not only makes things work but also makes it easier to modify it( for various reasons like fixing bugs, modifying logic, adding a new feature). Unlike good code, the bad code does the opposite i.e. makes everything difficult. “It was the bad code that brought the company down”, says Robert C. Martin in his book – Clean Code.
The primary reason for writing bad code into software programs is “Deadline”. Thoughts like “If I don’t do what my manager says, I’ll be fired”. Probably not. Most managers want the truth, even when they don’t act like it. Most managers want good code, even when they are obsessing about the schedule. They may defend the schedule and requirements with passion, but that’s their job. It’s your job to defend the code with equal passion.
To drive this point home, what if you were a doctor and had a patient who demanded that you stop all the silly hand-washing in preparation for surgery because it was taking too much time? Clearly, the patient is the boss; and yet the doctor should absolutely refuse to comply. Why? Because the doctor knows more than the patient about the risks of disease and infection. It would be unprofessional (let alone be a crime) for the doctor to comply with the patient.
Similarly, going by that analogy, it is unprofessional for programmers to bend to the will of managers who won’t be able to understand the risks of making messes. And most importantly, you will not make the deadline by making the mess. Indeed, the mess will slow you down instantly and will force you to miss the deadline. The only way to meet the deadline – the only way to go fast – is to keep the code as clean as possible at all times.
To sum it all up, control your urge to write bad code to meet deadlines. Deadlines are always there! Instead of writing bad code and meeting deadlines prefer writing good code even if you miss deadlines. Practice explicitly and deliberately to write clean code.Soon, with practice, you’ll become so fluent in writing clean code which will enable you to stay on track and finish on or before the deadline.
Happy Coding !!
Top comments (19)
I don't actually disagree with you, Jolas, but I find your treatment here naive and off-putting. Bear with me and I'll explain.
First, As
edA-qa mort-ora-ymentions, this is not a stark dichotomy, nor is it some sort of pitched battle. You want to ship good code to satisfy a customer. Your manager wants to satisfy the customer. You're both (ultimately) after the same goal.In fairness, you state this, but after you've pitched the programmer/manager dichotomy.
Furthermore, I take issue with:
I can't say this clearly enough: It's not your decision. Unless we're dealing with F/OSS you don't own the intellectual property you're creating. Stridently pitching a fit to management citing some sort of "professional standard" isn't professional, helpful, or even compassionate. #PragProg, chapter one: Offer options, not lame excuses.
Next:
This is provably false. Sometimes you do make the deadline by incurring technical debt. Making statements like "the only way" discredits your argument, because one can cite examples when you copy/pasted some code (or something similar) to get stuff out the door, Delivering Results.
Last in your summary:
First, I agree.
However, a professional developer will engage with Product Management about tradeoffs long before it comes to the "line in the sand" moment. To me, driving consensus and a great experience for the customer needs to be the goal, without devolving into "us"/"them" dichotomies with management.
Best wishes, sir. Thanks for putting yourself out there and sharing your views.
100% in agreement with Harold. Try working in a large company where the IP isn't yours.
Thanks for sharing your thoughts Harold Combs.
Stridently pitching a fit to management citing some sort of "professional standard" isn't professional, helpful, or even compassionate. - I disagree. As edA-qa mort-ora-y said, the clean code does not necessarily need to be pristine but it should be okay level clean in such a way that it is easy for maintenance. Making the product work with bad code will meet the goal of satisfying the customer, temporarily. But, when it comes to maintenance phase or feature addition you will spend even more time due to your technical debt, which both manager and developer don't wish to spend at a crucial stage when the customer wants the product to get its bugs fixed.
I think if you get into a good rhythm and are familiar with the problem at hand, you no longer really have to make that tradeoff (not that I can achieve this consistently)
Ben Halpern, thanks for sharing your thoughts.
To comment on your thought, humans tend to get attracted towards instant gratification rather than the process of working harder/longer for greater good and I think this will make people make the tradeoff and that's why I recommend my controlling the urge to make the tradeoff.
Yeah. But it gets complicated when there are whole teams, expectations, ignorances, etc.
And that's when coding conventions help writing clean code irrespective of team size.
In the discussion of good code versus bad code it's important to remember this is a spectrum and somewhat subjective. Though I generally don't write bad code, I certainly don't always write pristine code. I quite often produce "okay" code on the first pass, or if really pressed for time maybe "passable" code.
And in many situations this is all that matters. At a startup company it's important to do "okay" and "passable" code rather than "pristine" code. For a company on limited funding the need to ship working products is paramount to code quality (again, I'm not saying crap code is okay).
I covered this more in my articel Are we forever cursed with buggy software?
You will not always go faster by writing clean code. Quality clean code takes time (especially if you have a large code-base). Often there is an inverse relationship between code quality and development speed. So to meet a rushed deadline you either have to sacrifice quality or features.
You should strive to maintain a consistent level of quality by reducing the feature set to meet a deadline. This requires early and constant communication (with manager / product owner, client, etc).
Caveat: you should be willing to sacrifice quality temporarily if it's an emergency. E.g. You will go out of business if you don't meet the deadline. This is reserved for emergencies, because it is unsustainable, but it would be stupid to lose your job/company over code quality.
Quality code appears to be taking time. In fact, it is saving you from spending more time during maintenance and feature addition.
I hear you, but there is a point that I fear readers might miss.
In the short term, depending on your system, doing something the "right"/high-quality way can take far longer than a quick fix or hack. This is very important in the context of a deadline. It means you may meet your deadline to deliver a feature that would be impossible to deliver in the same time with quality clean code. However, you run the risk of crippling long term maintenance.
Anyway, time is relative. For most a "deadline" is short-term. Clean code is about the long-term, and while sometimes it's really just a mind trick that you think it will be longer, but in practice you run into the situations I described as well.
Developers have more time than they think normally. The tendency is to panic and engage in a mad scramble to make something work. I find a couple of long group think sessions lead to better outcomes under deadline pressures.
Yes! you have right. We have to re-write entire modules on our system because the code was written fast and with many "work arounds". We said "I understand the previous programmer because I would do the same with this deadline" it's a pain to add features or try to fix a bug. But our boss only thinks on the deadline, nothing more. We spend many nights and weekends fixing everything
I agree with you, but I would be more precise concerning the medical example. Of course, it would be unprofessional not to wash his/her hand before a surgery. But it is also unprofessional not to comply with the patient, you don't have the right to do whatever you want on the body of your patient, even as a doctor. Consent is important. Without consent you break communication and trust.
As a developer, I explain to my manager how I need to work, because we're partners first and foremost. With proper communication, managers can understand the risks of making messes.
We're mercenaries, it's our professional duty to say "I can do this faster but ....". The product owner take the decisions.
The doctor can comply but the patient must sign that he understood the risk of infection.
Ofc you can also refuse as a professional to do a bad code, it's up to us.
I agree with you basically,but the real world is not a book, unfortunate. Also I recommend all 3 "Clean ..." books to all developers.
You are so right, hope PMs/CPOs will see this article
yes indeed. bad code will slow you down. also i like the doctor example I'll keep it always in mind. thank you !