Why is it that #CleanCode is still the exception and not the norm in so many companies?
A very interesting question from Marcus Biel, who was the Director of Developer Experience at RedHat at that time posted on LinkedIn. That moment, I didn't have the time to go deep on this topic, but I reread the answers a couple of months later.
It's them!
People pointed at two groups mostly:
- project managers
- junior devs
Project managers are guilty because they want no more than one thing: kicking new features and projects out on the software factory door. They don't care about clean code at all, they don't even understand what is technical debt and without that deeper understanding "clean code" (anyhow we define it) is expensive.
Besides, "the amount of new developers doubles every five years" and they obviously don't know to how code in a clean way and the math implies that there is simply not enough senior developers to mentor them.
While these are all true, they simply blame others and the circumstances. These explanations are childish as they lack self-responsibility.
But I also found some more interesting answers.
It's us!
We have to say no
Eloy mentioned that in his opinion, sometimes it's better to say no as a developer. Or at least gently warn people that if they continue like that they'd shoot themselves in the leg. I can't agree with him more. Not surprisingly a conversation was spurred about the lack of mandate to say no as a developer, as an individual contributor. Again, it's easier to blame the circumstances and others.
But as both Eloy and another person pointed out, there is more than one way to say no. One is to simply step aside and move to another project if you don't feel that your expertise is welcome. Or you can be a bit harsher and remind your management that if they don't trust you, they are free to fire you. If you are a seasoned developer, how difficult would it be to find another job? It's not so easy, but still it's better than staying at a position where you are not valued and trusted.
I liked this subthread a lot because it emphasizes the responsibility of the individual, it brings up professionalism. In my opinion, if you are a real professional, you must be able to say no. More than that it's your duty to say so when you feel it's appropriate! I know it's difficult for the first time. But a good boss will value it. Even if due to some circumstances he will order you to take the dirty road, he would understand your reasons and not punish you for them. Well, if he is not a good boss maybe he'd be just pissed of. I already said. There are always other projects/companies to work for.
Clean code is difficult
Speaking about professionalism and difficulties, another reply I liked was about saying that #CleanCode is hard. As it requires serious efforts (at least in the beginning) and discipline not to accept anything but the best. It's not in the mainstream. What I like in this answer is that it doesn't toss responsibility away. People - we - are lazy and disorganised. People - we - tend to go towards the least resistance and if mediocre performance is accepted by the team, the individuals - we - will just perform on a mediocre level.
If you want to perform constantly on a higher level, you have to set up a framework that will force you to meet higher standards. Most of the people are around average - no surprise, it's fact by definition. If you can help others improve even better, but you are responsible for yourself. You have to push yourself to be better.
We have to drive the technical change and maybe the herd will follow you. Or at least a couple of them.
Let's do our job!
While it's true that many project managers don't even understand technical debt or clean code, I don't see it as a problem. Do they understand inheritance, immutability or the difference between different types of memory allocations? Some surely do, but many don't and it is not a problem. We do our job and when we have to then we explain and answer questions.
As professionals, we have to argue and say no when we think so. Hopefully, you are hired to give your best, to share your expertise, not to just act a coding monkey. Read how Yegor Bugayenko despised his hairdresser just because he did nothing but tried to please him.
I find that many people are afraid of acting as professionals. Sometimes it's because of negligence. They simply don't care. Do you remember Office Space? Will I make another dime? It's somewhere understandable, but it most probably means that you are either not real professional or you are at the wrong place.
Sometimes, it's due to impostor syndrome, which is normal. But you have to push through it. Others wrote about this in so captivating words.
Sometimes, it's not negligence, just fear and lack of experience. Seniors have to show the way. Have to show that you can step up for your opinion. People with experience have to foster a safe environment which is safe to speak and stand up for your professional opinion. Sometimes, introducing tech debt is acceptable, but if you just keep feeling that your opinion is not respected and the debt is endlessly growing, probably you have to step aside.
And while it's understandable that project managers don't understand all the details about what we do and they don't even care - why should they? - but it's our responsibility to translate our points to their language. It's not about ugly variable names, messed up indentations in vim. It's also not about lines of code in a class or the cyclomatic complexity of a function. It's solely about maintenance costs. Code Simplicity: The Fundamentals of Software makes a very good job explaining this.
It's difficult, I've failed and will fail at it so many times, but we should give it a try and then keep trying. It's our responsibility to make the management understand if they spend a little bit more, in the beginning, they will spend much less in the long run. Of course, it's market pressure and stuff. Sometimes it's more applicable, sometimes a little bit less. But do they like when their product hit the ground because of poor code? What if it means millions of dollars lost in revenue and market value? What if it means hundreds of lives?
Conclusion
It's difficult to define what clean code is. But probably it's like hardcore pornography. You can't really define it, but you know it when you see it. It's difficult to describe clean code properly, but if you encounter a clean pull request you recognize it with a smile of satisfaction.
What we have to keep in mind that the responsible is always us. Never them. We have to raise our voices, we have to explain and educate. And in case, we have to step aside. That's the only way towards more maintainable and reliable code bases. You think it's an exaggeration today, but tomorrow you might understand that it can be a matter of life and death, not just professional pride!
This article has been originally posted on my blog. If you are interested in receiving my latest articles, please sign up to my newsletter and follow me on Twitter.
Top comments (29)
Seems to me not enough people learn how to refactor code.
So many devs see getting something working as the final goal and move on to something else the moment it does. It's like taking a dump without wiping your arse.
Getting something working is only the first step of the process, once you've worked out how it can be done you need to work out how it can be done well. Taking a little extra time to tidy up your code and name your functions and variables sensibly will pay dividends down the line and make refactoring a lot easier.
lol nice comment while eating breakfast.
This has been my experience as well with developers (not just 'junior', but even more experienced ones)
Yeah, it's across the board it's not down to experience.
Sure sometimes you need to make do to meet deadlines and many times you'll even get away with just using whatever works. But I've also seen a fair few features delayed or become completely unfeasible due to code rot.
Also the more you refactor the more efficient you become at doing it.
Print that on a mug!
Exactly what's happening to me.
I was hired by a startup to refactor/rewrite previously written MVP (minimal viable product) implementations of their product ideas. The original intention was to make them real web applications that our investors can use in the near future. My colleague, who invited me to this job, created the foundation for us, based on clean code practices. We had healthy debates about implementation details, but never about principles.
As we progressed, first my colleague left, then the development team was extended with new hires (without real job interviews), so inexperienced (junior) devs and those with very little knowledge of clean, maintainable code and the worst practices of procedural programming slowly became majority. Code reviews became unhealthy debates about weather clean code and design patterns are something a small development team should even follow or use. They were even stubborn to adopt the industry standard coding-style we were using. PMs didn't have a clue, all they saw was the debate and that the modules, these guys wrote, worked. Pretty soon my stand to follow clean code principles (or even oop-principles) was said to be toxic for the dev team's day-to-day life.
I resigned. Today is my last day there. It's pretty funny to wake up to an article so accurately describing this situation. I shared it on Slack with the others.
Thanks for sharing! And good luck with your new job? Have you already found one or are you taking a break?
I'm taking a break for a month or two. I want to spend this transitional period to learn new craft; python is number one on the list. I should also catch up with frontend, as I have been doing only backend php stuff in the last few years. I also want to learn the basics of video editing, as a hobby. Active recreation, while licking my wounds and trying not to be this very disappointed -- that's the plan. ;)
I just did this. I was re-hired by a consultancy I used to work at (and almost got fired at) because they needed a strong .NET team lead. I thought I was set...principal consultant and team lead by age 27? I let that shit get to my head way too much. When I was brought in everything was a disaster. The .NET team had been without a lead for several months, and half my team was distributed so I was unable to directly interact with them at all.
A lot had changed in the company and I was thrown into the fray with no training on how to be a manager, what their management methodology was around here, what my roles and responsibilities were, nothing. Instead of the week long orientation employees are supposed to get, I was given a condensed 4 hour version which was basically filling out HR forms.
I had no authority to make clean code a goal or to fight technical debt. We had a "development" manager who had been at the company a lot longer than me (was actually my old supervisor), but on the org chart we were equals and both reported to the VP of Application Solutions. He incessantly micromanaged me and the project teams I was on and would contradict everything I had tried to put in place. "We're just proving this (offshore development model) thing works; you can't be wasting time focusing on things like that." "This sprint has to succeed, how many hours did you just waste fixing bugs? How are we going to win the client's trust if we don't succeed this sprint?" (It was a bug in password generation...)
There was a lot of obsession with "successful" sprints where if all the work didn't get completed, it was a "failed" sprint, as if all the work we had done was in vain. For reasons never explained to me, I wasn't allowed to take tasks off the table even though I was supposedly in charge. I basically had no authority and was constantly getting lectured about how this isn't how a principal consultant acts or I can't blame the client constantly for all the technical debt and lack of documentation, I still have to meet sprint deadlines which were estimated when I had 0 knowledge of the underlying system.
I quit, I did so quite unprofessionally unapparently. But I live in a "right to work" state, so I guess it is unprofessional when I use my rights under that to leave immediately without having to give reason, but it's cool for them when they fire people without warning? I've never been so stressed in my life.
The only mistake I made was I did not have substantial savings for my time off. I actually intended to try and start consulting independently, but my efforts keep failing and I am broke as hell. I found a much more independent job on a team which takes pride in their code instead of passing over half-assed projects to clients and patting ourselves on the pack for how much "business value" we added.
The time off has been really helpful in terms of learning. I am starting to get a grasp on DevOps, I reconnected with embedded devices as a hobby, and realized I don't really want to be a full-stack .NET guy anymore. I've been learning Ruby and am looking for open-source projects to help out on to make a name for myself. Three more weeks and back to the job!
To my surprise source code of Android operation system look so nice that I would gladly call that "clean code" instantly. And it is extensively unit tested too :)
Example - ActivityManager.java
cs.android.com/android/platform/su...
It's just that 6k line long class that is a bit too long :D
Its a catch 22, An experienced developer understands Technical Debt better than an experienced Project Manager, Project managers are mostly MBAs (thats how companies hire them), some are developers but they probably left development and have no idea about how to write code as they forget after doing their MBA.
Problem also lies with developers, Developers are little poor when it comes to manage a Project, creating milestones, achieving enough strength in product to make a perfect release, these are tasks that developers don't even care about.
The solution lies in, teaching developers concepts of project management and continuing both in parallel, is far better than someone with MBA degree. Understanding importance of release cycle and balancing code quality, both should be prime responsibilities of Project Manager. But mostly they are only involved in Release Cycles.
Last year I did code review of one project of one of high revenue company(close to billion), code was written 14 years ago and had lot of SQL Injection bugs. PM had six figure salary in USD. Company didn't like the review as the PM was very loyal to them. They were certainly in huge technical debt as they had difficulty in going Mobile.
I suspect that Universities or MBA Course Designers do not weigh Technical Debt at all.
Even as a developer, if you raise your voice, it will just serve as a small statement in future as "Look what I told you", everybody goes with Label (Degree, University), not with your voice. In such situation, you can only raise your label.
It's not their fault, businesses do rely heavily on degrees, and they will listen to you if you can present your idea in the form of financial values. Unless Technical Debt appears as a dollar value, it has no value.
Yes. I think it's much easier to identify what unhealthy code is (I just wrote a book about this).
Speaking from my own experiences, I would have to agree with your points.
The main issue I've seen come up time and time again is:
Most devs (even those with years of experience) don't even understand how to write clean code. Or, if they do understand in theory, can't do it in practice.
Some of devs who've produced the worst code I've seen think that they are writing great code...
These also tend to be the developers who aren't interested in learning anything new and challenging themselves.
So... how can they "say no" to projects that ought to cause some refactoring? They can't because they don't know that refactoring needs to be done. Or they just don't know how to 🤷♂️.
I've seen a lot of junior devs who never get mentored, and if they do, not well. There does seem to be a major shortage of devs who understand how to clean up their code and how to identify unhealthy code.
I think your point about being lazy is true. If we are technology professionals, ought we to take our craft seriously? Ought we to learn how to identify unhealthy code and how to fix it?
I think so!
Clean Code emphasizes long-term maintainability over immediate results. And often immediate results are premium: there is no point in long-term maintenance if you can't win the demo next week/impress the VC tomorrow/score the POC next month, and therefore have no long term to talk about.
Add to this low experience, incomplete information, communication issues and you pretty much can explain most projects.
While Clean Code is an important discipline to know and practice (if only to raise the level of what we can write everyday), life is not perfect and does not always value perfect solutions.
On the surface, this is correct. However, "long-term" in my experience starts showing within a month of development.
That is: If you rushed and prioritised immediate results, you will begin to stumble and lose pace within a month.
Not doing clean code/architecture and other practices (like TDD, CI/CD, etc.) from the start is sensible only if a project is estimated to not last longer than a couple of months. That is - if the entire feature set can be completed after a couple of months and there are no new feature requirements after that. Ever.
I have never seen a project like that except prototypes & demos.
For further reading, check out these two articles by Martin Fowler:
martinfowler.com/bliki/DesignStami...
martinfowler.com/articles/is-quali...
Tight deadlines. Pride/Ego. The wrong architecture for the task. Sounds like my first job.
This article just reminds me of why I loathe traditional content management systems. They're probably the biggest accumulators of technical debt by a large margin.
I think it's compounded by a team who pride themselves in being CMS developers.🤷♂️
Couple reasons as answer for the question title:
1) deadlines (no time to polish/rewrite/refactor)
2) difficulty (clean code is hard)
3) clean code is somewhat subjective, so its hard to agree on specifics
4) because its hard, statistically, 50% devs are below the average, so its hard to expect them to produce top results
5) deadlines. nobody is paying for great polished code (mostly because its impossible to explain to them that its worth. And in MVP phase, its a good thing - you dont want to have clean code, because project might be killed in a month because it took too long to ship. Clients pay for features/projects.
60% of a project's expenditures come in the maintenance phase of the project. I think more companies need to realize what a huge investment they are making. That's my favorite go-to to justify my position. That and handoffs to the next developer. Is this something you want to actually maintain yourself someday? Or are you going to keep on paying consultants $160/hr every time you need to make a change because you don't understand the code?
I suppose I don't quite buy into the whole MVP thing either. What good is it if I ship a product that sucks faster than anyone else? Users aren't going to be impressed when it is buggy as hell and they are paying to beta test things.
That's a very good point, I've also tried to use a similar one with management and at presentations. There is a very good book that can underpin this argument. Code Simplicity in its third chapter introduces the equation of software design which includes the effort involved in introducing a change. Not surprisingly for us, it talks a lot about how much maintenance costs matter in those efforts. I think it even goes further than 60%, but the point is there.
MVP doesnt mean it has to suck. Quite the opposite. It has to provide value to the user that has a need.
I would add one point, or rather replace "junior devs".
This point is tutorials/bootcamps/academies or things of that sort.
In my opinion, there is a big difference whether the developer has had a formal education, or was pretty much self taught.
It's easy to make a tutorial/lecture on ifs, loops, generics etc, but rarely can we find tutorials that cover design patterns, since that requires more time and context to explain, or can sometimes even be considered "too advanced".
In formal education, however, those topics can be explained in the period of half a year, rather than 10 minutes :)
Whether you choose to listen during lectures in the uni is another topic :D
Honestly, I've never learnt about maintainable code at university. And if I have a look at the curriculum or some programming courses that I'm aware of, they don't really care.
Then all this becomes the more senior colleagues' responsibility in the different companies.
Well, at my university I had a whole course about patterns and architecture. I would also consider that a part of maintainability.
However yes, I agree that most of the maintainability is learnt by doing, especially with a guidance of senior :) I have probably exaggerated a bit :D
Just because we want to maintain clean and helpful code, doesn't mean the specific 'clean code' book ideology is perfect or even suitable in some cases.
Should we call it maintainable code? After all, it's not about self-serving poetic code, but about code that is extensible and relatively cheap to maintain in the long run.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.