Maintaining code quality when nobody cares

I've tried this approach in the past and and it has made me very bitter. Eventually I realized that the company I worked for enforced no accountability for bad code, so I would often open the solution later and found a pile of ugly hacks or other mess. Code reviews? Refactoring? "We don't have time and no one is going to pay for it". Eventually you come to a conclusion that if no one cares then why should you? If any effort on your part is going to be negated by your coworkers anyway then why bother? How do you push back against a corporate culture that has been there for years and no one seemed to have a problem until you came along? Maybe it's possible when you're a senior dev that has control over a project, but as a mid level developer I've never been successful at enforcing any standard - people usually don't care because it would mean additional work and effort on their part and they still get paid the same regardless of the quality of the code.

There needs to be a sense of ownership and pride. Even my side projects are written then rewritten over and over again until I’m personally satisfied with my approach and the quality of the code. If I use a hack to get something done on code no one but myself will ever see, I still leave a shame comment (&#x2F;&#x2F;mqudsi: this is an ugly hack because I was too lazy to clean up access to this global variable. Fix me.)<p>We aren’t dealing with anything new in terms of work ethics and quality control in software development. I maintain my code quality the same way a carpenter 2,000 years ago would have cared about how well the insides of a finished product are designed, whether it exceeds its required specifications, what other carpenters would think of their work, how they would feel if a future apprentice or master saw what they created that day, and so on and so forth.<p>Additionally, I place a premium on “skills learned or perfected” over “bugs closed or features implemented.” If xx is better implemented via an approach I haven’t used before - well, here’s my chance to learn how to do that. Sure, it’ll delay the process. But that’s where technical debt comes from. I may only end up writing ten lines of code that took me 17 hours to figure out and understand, but if those are the <i>right</i> ten lines of code then whatever else I could have or would have written or accomplished in those 17 hours doesn’t matter.<p>When the goal is “closing JIRA issues or GitHub PRs” and the only metric is how many bugs you closed that day, code quality will suffer. But instill that sense of pride, take ownership in your work and create an environment where others are encouraged to do the same, and it’s a different matter.

You need to get the programmers together and agree on a coding guideline, a linter and other architectural fundamentals.<p>Then the gardening phase begins, which means no refactoring or warning or style fixes unless you touch the code to do something meaningful like a feature or bug fix. Leave everything you touch better than before. Dissolve big classes and functions into smaller ones. Write a test or two for the smaller side effect free function you just created.<p>It takes a ton of time and patience but every week the kraken loses a tentacle. And once most code feels untangled you can embark on a refactor since all of the parts are movable now.

Some things I&#x27;ve learned about code quality in organizations where the quality is terrible:<p>1. The problem starts with culture. These organizations are run top-down by people who don&#x27;t understand coding. Sometimes they are ex-engineers, but that&#x27;s usually about as good as non-engineer.<p>2. These organizations are systemically incapable of determining good work from bad. Who on the team is performing and who isn&#x27;t? They can&#x27;t tell. They will usually default to seniority (meaning how long a developer has been with an org, not how good they are).<p>3. These organizations reward fires that are put out. They do not reward fires that were prevented from happening in the first place. Those &quot;senior&quot; developers will frequently be rewarded for putting out fires they caused.<p>4. If you do a lot of work that prevents fires and that means you weren&#x27;t working on features or bugfixes, you are going to get punished, not rewarded because to the people above you it looked like you were doing nothing.<p>5. If you&#x27;re going to do this kind of work, you need serious intrinsic motivation.

&gt; It turned out that the project I was invited to started as early as 2014. Do you think it means that it’s big and complicated? Then you’re right. And it’s also really old.<p>Is it just me, or is less that four years not &quot;really old&quot;?

&gt; Code review at the end of the task.<p>This is something I still struggle with. I think it&#x27;s a result of an open source tool (GitHub) bringing bits of culture along with it.<p>In open source world, all contributions are entirely voluntary, and most follow the Benevolent Dictator For Life form of governance. So you do a bunch of work, and you submit a polite request for the BDFL to pull your work into the project. He or she may decline your Pull Request, request a long list of changes, or just wait ten years to give any response at all.<p>In a business setting with hourly pay, deadlines, and co-workers chosen for you, not by you, it makes less sense. People tend to wait until the last minute to give or request feedback which leads to a lot of thrown-away work. Unfortunately, willingness to throw away work becomes a mark of pride at some places. Maybe enterprise projects need some kind of &quot;managed push&quot; system instead of a &quot;pull request&quot; system.<p>Edit: &quot;Unfortunately, willingness to throw away work becomes a mark of pride at some places.&quot; to elaborate, the thing that makes this unfortunate is that the person assumes that throwing away work is necessary for code quality to stay high. By requesting feedback at intervals (which is what the author of the article recommended), you can avoid throwing away work without sacrificing quality.

Quality means doing it right when no one is looking. - Henry Ford

I’ve often wondered about a twisted form of asynchronous “pair” programming: One person codes quickly, creating mediocre code that achieves the goals, the other person cleans the code up and modularizes it.<p>I’m drawn to this because they are two different mindsets that achieve somewhat conflicting goals, and the tasks can be separated with minimal communication overhead.<p>Thoughts?

The largest burden to raising code quality I have ever seen is the conflicting burden of maintaining product quality.<p>That is to say, many of the loudest proponents of code quality are the first to completely disregard the customer quality points in the product.<p>Yes, there are fun meta arguments about how higher quality code can let you deliver faster. Nobody is going to wait for you to get to that point, though. You have actual users and customers today. Their problem is not the code&#x27;s intrinsic quality. Instead, they are trying to use the product. If you can&#x27;t tie their concerns to visible metrics that you can move more effectively than someone else, then you are likely just yelling at your peers. Not helping your customers.<p>And please, do not make the mistake of thinking you can push massive changes without breaking things. You will cause regressions. Period. If the changes are truly needed, you will make up for them with more rapid progress afterwards. Don&#x27;t punish your users, but don&#x27;t lie to them either. Respond and get so that you can measure your impact before they contact you about it. Reach out, apologize and make right.

I&#x27;ve had business people tell me I should stop writing tests so I could go faster, even when I&#x27;m producing significantly more features than the developers around me who don&#x27;t write tests. Once you get good at testing, writing code with tests is faster than writing code without tests: the challenge is the four to six year learning curve to get there.<p>I think we just need to stop telling people that code without tests is an option. It is an integral part of being a software developer, not a nice-to-have afterthought.

I am a Dev Coach. This means companies hire me to pair program with their developers and help them focus on &quot;technical excellence&quot; which is manager speak for &quot;code quality&quot;.<p>Here&#x27;s what I&#x27;ve found:<p>- Most companies <i>don&#x27;t actually care</i> about code quality. This is especially true for the ones that hire me. The managers that bring me in would much rather play-act than make the systemic changes required for their teams to operate with improving quality.<p>- There are systemic challenges to code quality in these environments. Namely hiring practices, performance evaluation, and priorities (budget&#x2F;timeline). Obvious.<p>- Nobody can explain the benefit of code quality in terms persuasively enough to managers that they will accept the cost. I&#x27;ve never seen it done. It must come from somewhere else. This is why companies with more technical people in positions of leadership tend to have this problem less IME. Frankly I think this is why we use words like &quot;technical debt&quot; either that or it&#x27;s a tautology. There&#x27;s an irrational lack of discipline in this area akin to credit card debt.<p>- Furthermore, software itself does not matter to these companies.<p>That last one is the most important and it is not meant to be normative. I&#x27;m not saying software is not of actual importance. I&#x27;m saying it is not treated in the company with any importance. Software development is viewed as a necessary evil, not as an opportunity for competitive advantage.<p>The difference between my clients who view software as a necessary evil vs. a competitive advantage cannot be understated. It is immense. Often these companies with different perspectives are competitors in the same industry! You can guess which ones are growing happily and which ones are struggling to cope with changes to their business.<p>There are companies where the ratio of &quot;business&quot; people to IT is 1:3 and they balk when you tell them they&#x27;re essentially a software company.<p><i>&quot;No, we&#x27;re a mortgage company.&quot;</i><p>Ok how&#x27;s that working out?<p>What I&#x27;ve decided is to start doing a better assessment up front as to the actual priorities and perspective within these companies when choosing a client. There are companies where the light bulb is coming on and it can be a blast to work with them. In the current climate I would advise everyone to just flat out avoid companies that don&#x27;t see themselves as tech companies. Work for companies that see themselves as tech companies or are seriously trying to change that perception internally. You can find companies like this in all industries. You might be surprised.

In many companies I worked that were like this, other developers also wanted to fix these problems. So, talking with them is also a good start I would say, if you get get one more colleague to work kind of right from beginning is a nice start too. Normally, QAs and test automation engineers will be all for improve the situation. Being a bit more vocal on these problems, but it is important to choose what should be the 1st problem to be tackled.

Code quality depends on you. If you are maintaining the system then for your own sanity, clean it where you can. If you are writing the system for someone else to maintain, clean it where you can, because you will probably be the poor sod who will have to maintain it later on.<p>If you can&#x27;t clean it now, write down everything you know about the system, all those little annoying assumptions that nobody else has documented. Do this for your own sanity.<p>Don&#x27;t be afraid to rebuild something if that will get you out of a bind. It will be for your own sanity to do so.<p>The pragmatics of cleaning up code is for your own sanity, unless you intend to leave in the near future. In that situation, it will be someone else&#x27;s problem. But remember that in your next job, you&#x27;ll become the someone else.

You build version 1 to throw away, version 2 to be upgraded, and version 3 to be maintained.<p>If you never get to version 3, you never get the opportunity to worry about code quality.

i used to be a software archeologist at a previous job. dig a small hole and uncover the artifacts and ruins of a previous project civilization.<p>please, for humanity, write documentation. even better if it&#x27;s after the code is written. why does the payments-smart-broker have a direct connection to the translations database if it doesn&#x27;t have a ui?

It doesn&#x27;t matter how pretty the code is if it does the wrong thing. Software quality is the interface , not the &#x27;code quality&#x27;. Usually code quality helps build higher quality software, but it isn&#x27;t sufficient.

I hit almost this exact situation at my last gig. It came down to one of two things: was I okay with complete job security while being completely bored and apathetic all day, or would I take a bit of a leap of faith if it meant getting out of a rut? I chose the latter and it worked out. Maybe if I was a higher-up I would have tried to fix things, but it wasn&#x27;t really my responsibility at the time. I&#x27;m not completely absolved; I could have tried harder to institute things like PRs and linters, but my give-a-fuck was far below the threshold it would have taken for me to really take action.

When code quality is hard to enforce, one approach is to at least ensure that the design of public APIs, and boundaries between components reaches some level of quality. This is usually a smaller surface to monitor than the entire code base, and it allows islands of good quality to emerge. Good boundaries also will allow for easier refactoring over time of the really bad code.

Ahhh, life. If only everything were perfect. Keep pushing but don’t be surprised by the pushback and despondency. But keep pushing, for yourself, and others who want to care.

One huge problem is that there’s no context-indepedent definition of quality code, and criticisms often suffer from hindsight bias.

This is the second post from this website to get upvoted to the frontpage within 48 hours. I hope this is natural.

This is why I’m keen on automating code standards&#x2F;quality away. We’ve recently launched JS, CSS and Vue.js support in <a href="https:&#x2F;&#x2F;StyleCI.io" rel="nofollow">https:&#x2F;&#x2F;StyleCI.io</a> to help more developers standardise their code.