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 ...
For further actions, you may consider blocking this person and/or reporting abuse
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.
I tried that no option. All the bigwigs in charge of my program were added to an email, and I was basically asked to say no to all of them. That was fun. I said it would work for now but difficult to iterate on and got away from what felt like the Eye of Sauron staring at me. Now going with the find a place that cares option.
Love this so much
This conclusion is priceless 😍
LOVE THIS LINE: