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 m...
For further actions, you may consider blocking this person and/or reporting abuse
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 !
Missing deadlines is acceptable as long as it's communicated adequately early enough for the manager to take measures.
Absolutely!