17 ms·

Maintaining code quality when nobody cares

314 points by fodoj 9y ago

crdoconnor 9y ago
Some things I've learned about code quality in organizations where the quality is terrible: 1. The problem starts with culture. These organizations are run top-down by people who don't understand coding. Sometimes they are ex-engineers, but that's usually about as good as non-engineer. 2. These organizations are systemically incapable of determining good work from bad. Who on the team is performing and who isn't? They can't tell. They will usually default to seniority (meaning how long a developer has been with an org, not how good they are). 3. These organizations reward fires that are put out. They do not reward fires that were prevented from happening in the first place. Those "senior" developers will frequently be rewarded for putting out fires they caused. 4. If you do a lot of work that prevents fires and that means you weren'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. 5. If you're going to do this kind of work, you need serious intrinsic motivation.
- ataturk 9y ago
  A big problem in the IT world today is that #1 is no longer the case--it is marketing departments that are driving a lot of software development and they don't care about standards, code quality, tests, anything. It's a bad culture change.
- W0lf 9y ago
  Yes, you summed up perfectly what I've been experiencing in my professional career for quite some time now.
- carlmr 9y ago
  So what is the prescription to find a company that doesn't check these 5 boxes?
  - pjmlp 9y ago
    Start your own.
  - crdoconnor 9y ago
    In general the companies that don't both A) pay better and B) are located in tech hubs / do remote work. So, go for more money, prefer remote or in a tech hub. You can also ask during interview about the coding experience of the manager you will report to. Usually they are up front about it. If you turn them down, do us all a favour and let the company know that was why (more coding managers and fewer MBAs please!). I'm not gonna lie, it's not going to be possible for everybody to avoid this kind of company, especially in the more backwater places. I left Singapore because I basically found one company that didn't obviously follow that pattern. They frustrated me too for other reasons so I didn't take their offer. I think that this is one of the most underrated reasons for the formation of technology hubs and one reason why Singapore, in spite of really trying to become a "silicon valley of asia" (VC money: check, money pumped into education: check, huge startup grants: check) just won't, and will bleed rather than attract talent.
    - petagonoral 9y ago
      > You can also ask during interview about the coding experience of the manager you will report to. Yes, for tech leadership. No for people management. Simply put, too many people in people management positions who were "technical" x years ago. This leads to them making technical decisions that their team should be making, which they absolutely should not be doing.
      - crdoconnor 9y ago
        >Yes, for tech leadership. No for people management. A good tech leader can handle people management too. A good "people management" leader can't handle tech. You want both. >Simply put, too many people in people management positions who were "technical" x years ago. This leads to them making technical decisions that their team should be making, which they absolutely should not be doing. Good tech managers will trust the judgement of their team and know when to give them agency and when to overrule them (there are sometimes legit reasons to do it).
- maxxxxx 9y ago
  In general I agree with your points. But you seem to have some gripes with "senior" engineers. I think if you left that out your points would be better. In the end it comes down to management not understanding the work and rewarding unproductive behavior. This has nothing to do with "junior" or "senior."
  - l_t 9y ago
    While I haven't personally worked at such a company, I've observed some "toxic" workplaces and found that typically it is, in fact, the senior staff who are the biggest part of the problem. Only certain types of people achieve seniority in a toxic organization, and they are typically those who (deliberately or incidentally) benefit from the culture that everyone else hates. They build a clique and try to build influence while the new hires -- who actually care about doing things well -- turn over every 3 months. This is all anecdotal, of course, but I do think that in an engineering-hostile organization, the senior staff should typically take the brunt of the blame (just as in a successful organization they would take the lion's share of the credit).
    - maxxxxx 9y ago
      I guess that makes sense. If the org is dysfunctional the best people at some point will have left leaving the not so good people. But I think that change often has to come from management. Even if you are senior you often can't do much about stupid management other than leave.
  - crdoconnor 9y ago
    It's not seniority per se (I count as senior), it's people with long tenure. If, as a developer, you've had a long tenure in an organization with bad code that's usually a bad sign.
- ConceptJunkie 9y ago
  I would add that management will gladly save an hour now, even if it costs 10 hours down the road. I'm getting really tired of the message from management of "Here's what we should do, here's why we should do it, and here's why we won't." In other words, they will periodically acknowledge that there are systemic and cultural problems that seriously need to be addressed, but consistently fail to address them.
- ashelmire 9y ago
  ...wow, this is my organization to a T. Needless to say, it's time for a move upward and outward.
- foobarrio 9y ago
  I like this list. What I have found about point #4 is that even teams that try to actually measure performance in a meaningful way will miss things. If the quality of the software is slowing down feature releases, causing fires but is not being measured, you can make some headway with presenting ways to measure code quality so that your work shows up on their radar. This is difficult with such a subjective word as "quality" but tracking number of fires of time would be a good way to show that the way you develop is better than other people. The other thing that companies miss are employees that help other employees in a mentoring sort of way. These people essentially cast a buff on everyone they work with. These buffs can be in the form of better tools, improved workflows, recommending reading material, new technologies etc. Unfortunately it seems this is up to that person's superior to recognize their value and fend for that person to upper management. I feel like it's easy for me to identify peers that cast buffs but not sure how easy it would be for a manager to identify such characters.
navium 9y ago
Quality means doing it right when no one is looking. - Henry Ford
- marmaduke 9y ago
  A clever quote saves us from having to think! (paraphrased from some original quote I can't remember)
  - jacquesm 9y ago
    Yes, but in this case someone else did the thinking for you and it is actually pretty accurate. If the only time you care about quality is when you are being checked, audited or supervised then it will not work. Quality needs to be infused all across the board and needs to be reinforced from the management downwards throughout the whole organization, not just in the quality control department. So Ford was definitely on to something and beat mr. Demming by a couple of decades on that particular insight. It's no surprise that both of them had a lot of these insights in the automotive industry to begin with, where warranties can very rapidly eat up the profit margin on the sale.
    - marmaduke 9y ago
      isn’t this like saying quality code is code that is correct without unit tests? They seem unrelated
      - navium 9y ago
        Or more like, you write unit tests even if no one asked you to.
      - flynnieous 9y ago
        They are related in that quality code is code that is both correct now and can easily be made correct when things change--and things always change. Unit tests are what enable correctness in the future.
leibnizwasright 9y ago
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.
oldandtired 9y ago
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. If you can'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. Don'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. 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's problem. But remember that in your next job, you'll become the someone else.
- Pica_soO 9y ago
  If you dont get the time necessary- lie to your clueless superiors- tell the story about the complicated feature, that needs hours more- they will never understand how much a well made library will save them future time, so you are actually helping a clueless fool to do a good decision with that little lie.
  - majewsky 9y ago
    It's sad that this gets downvoted, because it's the only realistic approach in such a situation (which is also sad).
    - leibnizwasright 9y ago
      Yes, I don't see this a problem, normally releases get delayed, if you get more time to develop better, then why not? I always saw testers talking with product owners and managers about one or other developer that was slower but had delivered less defect.
      - ConceptJunkie 9y ago
        I know that feeling. I'm one of those developers that is slower than a lot, but I also know from long experience that when I deliver something, it's solid. It's not that I don't make mistakes, but that I work in a way that helps to minimize them when I do make them. It takes me longer to get things done than the hotshots, but there will usually be fewer problems and the problems that do exist will usually be much shallower. And unlike a lot of people my work contributes to a net decrease of technical debt. I'm not saying this to brag, but to emphasize that this is what it takes to do quality work.
pgsandstrom 9y ago
> 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. Is it just me, or is less that four years not "really old"?
- jacquesm 9y ago
  The number of years a piece of software has been alive is not always a good indicator of how old it is. It can be 2 years old and in outright legacy territory. Some people are working hard to replace one legacy project with another. Software does not age well when it isn't constructed properly.
  - jimmy1 9y ago
    In my opinion, when speaking of "legacy software", we should place a stronger emphasis on the actual meaning of the world legacy rather than the usual pejorative. Meaning that: this software has created a "legacy", in some form or fashion. Whether that legacy was it was used in the past to build the business, it paved the way for some standard or better practice, or it simply outlived it's time. Downvotes are usually reserved for when a comment is low quality or not relevant to the conversation at hand. Could you please explain if my comment fit into these categories for my own learning? Thank you.
    - eitland 9y ago
      Like it or not but legacy has taken a new meaning in software. I think it is Michael Feathers who defines it as code without tests in "Working Effectively With Legacy Code". (That said, I didn't downvote you and I'm also tired of the abuse of the downvote button. I think in your case they downvoted because it seemed like unproductive nitpicking.)
      - jacquesm 9y ago
        I like that definition. Maybe another one: code that nobody knows intimately.
dep_b 9y ago
You need to get the programmers together and agree on a coding guideline, a linter and other architectural fundamentals. 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. 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.
- crdoconnor 9y ago
  IME linting picks up about 99% fluff (ooh look there's some whitespace on a blank line) and 1% potential issues highlighted (usually minor). The reason people like to default to linting when "fixing code quality issues" is purely because it's 100% objective and measurable, not because it picks up the truly important issues. It doesn't. Edit: I am aware that coders have OCD impulses which can be sated with a linter, but priority #1 when fixing spaghetti code is unraveling the spaghetti, not sating your need to see }s in a place that makes you feel better.
  - mathgeek 9y ago
    Most linters allow you to disable whitespace linting. Good tools allow you to learn to use them better.
  - simonpantzare 9y ago
    I'd argue that there's a significant mental overhead reading code when it doesn't follow the same conventions, and that enforcing a style guide is a matter of having no broken windows. But of course there's no point trying to make shit look good.
    - dep_b 9y ago
      A linter and code conventions are a way to make code more consistent and easier to switch between. At times it becomes hard to see what code you wrote and what somebody else wrote, which is a good thing. If I open a file and everything "just feels wrong" but I can't change it because enforcing my personal preferences are just my personal preferences is just making things worse that really takes some valuable energy away I could use for actually improving things. But I can get used to a coding guideline that's not 100% my preference but a well enforced and consistent one. Knowing that if I fix indenting and naming the fix will not enrage someone else.
ataturk 9y ago
What the author is too young to realize is that there is no development path for him(?) as a programmer. Companies don't care if you have time off or hobbies, or a wife, or anything. They don't hardly give a shit that you need to breathe air.
tboyd47 9y ago
> Code review at the end of the task. This is something I still struggle with. I think it's a result of an open source tool (GitHub) bringing bits of culture along with it. 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. 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 "managed push" system instead of a "pull request" system. Edit: "Unfortunately, willingness to throw away work becomes a mark of pride at some places." 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.
- detaro 9y ago
  > Maybe enterprise projects need some kind of "managed push" system instead of a "pull request" system. What would you do different in "managed push"?
  - tboyd47 9y ago
    Not sure? Maybe letting developers push directly to master, with an automated test run at each commit and a project manager or tech lead in charge of tagging and deploying releases?
- pjc50 9y ago
  > willingness to throw away work becomes a mark of pride at some places Is this a typo for "willingness"? Code review is important not just for preventing junk from entering the codebase but for ensuring that someone else has seen the thing and has some idea of how it works. I agree that "pull request" is the wrong terminology for a commercial environment.
swaqny 9y ago
hello https://www.hello123.com https://www.hello123.com
realworldview 9y ago
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.
jbrooksuk 9y ago
This is why I’m keen on automating code standards/quality away. We’ve recently launched JS, CSS and Vue.js support in https://StyleCI.io https://StyleCI.io to help more developers standardise their code.
trevyn 9y ago
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. 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. Thoughts?
- JoeAltmaier 9y ago
  I worked like that with a colleague of a decade in a startup environment - we produced tens of thousands of lines of embedded code in a year. It can work with a close understanding between the two people.
- alextheparrot 9y ago
  I see this often in a slightly different context - people who write libraries well and people who write application code well. One tends to be generalized, focused on end-user ease of use, while the other is first and foremost attempting to achieve business goals with the available tools.
- hinkley 9y ago
  Eventually you feel like a janitor or a babysitter. The problem is that the guy making the mess gets credit for things and the guy cleaning it up keeps bad things from happening because of him. If your boss is not just the right type then you will become the bus tribute.
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
- hindsightbias 9y ago
  There used to be a time where every new coder spent a couple of years learning/maintaining their elders' code - fixing bugs, porting, optimizing, learning about how the environment(s) integrated. The concept of journeyman in sw was a thing, and mgmt/team expectations from the youts was appropriately gated. Now it's different (outside of HW orgs), but as I look out a decade or so, I'd rather have a part-time retirement job "cleaning up" interesting projects than travel/consulting.
ComputerGuru 9y ago
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 (//mqudsi: this is an ugly hack because I was too lazy to clean up access to this global variable. Fix me.) 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. 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 right ten lines of code then whatever else I could have or would have written or accomplished in those 17 hours doesn’t matter. 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.
- ionforce 9y ago
  > I place a premium I think the problem is are you saying this as an individual or are you saying this as someone in leadership with power. Place a premium all you want. But if you're a grunt, that opinion is going straight to dev null.
  - laythea 9y ago
    I laughed at this :)
- LrnByTeach 9y ago
  carpenter 2,000 years a very good analogy with quality of code. This is very good reward system for developers . placing a premium on “skills learned or perfected” over “bugs closed or features implemented” > 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. > 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.
ManlyBread 9y ago
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.
- Terr_ 9y ago
  I'm in a similar situation right now: The company thinks that any feature-wanter who's loud enough is automatically "one of the product owners" (always plural, always ambiguous) with the ability to tap an outsourced development house for "additional capacity." I regularly come across months-old new code that the main team wasn't even consulted about. Reinvented caching layers, eval'ed code in database tables, file-download endpoints that accept any path from the browser, and code with so many immediate red marks that the writer can't possibly have been using an IDE. It hurts my pride that I've been here for years and can't seem to change the pattern, but perhaps at some level it's basically codependence [0] and I have to leave the sick corporate-entity until they really "want to change." [0] https://en.wikipedia.org/wiki/Codependency https://en.wikipedia.org/wiki/Codependency
  - SIRHAMY 9y ago
    At that point, you could probably bring in Legal. Not only are these just poor coding practices, but some of these things are very serious security vulnerabilities. If you've got contracts with clients, or even if you're licensed straight to individuals, it's a good bet that you're breaching some data security/privacy rules. Legal would definitely want to know and take steps to correct.
logfromblammo 9y ago
You build version 1 to throw away, version 2 to be upgraded, and version 3 to be maintained. If you never get to version 3, you never get the opportunity to worry about code quality.
- justin_oaks 9y ago
  Every company I've worked at will ship version 1 to production and proceed to build on top of version 1 forever. Of course, by version 1 I mean "the proof of concept I showed someone else".
  - logfromblammo 9y ago
    A log can dream, can't it? It's the classic bait-and-switch of corporate development. They get you in the door by pretending they have a rational process, and wait until you're invested before dropping the facade. I, too, have never worked for a company that ever considered retiring software ahead of immediate necessity. Generally, it's always "we don't have time to do it right in the first place, because we're too busy fixing all the stuff that is broken right now."
deleted 9y ago
[deleted]
Ocerge 9y ago
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't really my responsibility at the time. I'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.
taeric 9y ago
The largest burden to raising code quality I have ever seen is the conflicting burden of maintaining product quality. 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. 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's intrinsic quality. Instead, they are trying to use the product. If you can'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. 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't punish your users, but don'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.
mempko 9y ago
It doesn't matter how pretty the code is if it does the wrong thing. Software quality is the interface , not the 'code quality'. Usually code quality helps build higher quality software, but it isn't sufficient.
ryanmarsh 9y ago
I am a Dev Coach. This means companies hire me to pair program with their developers and help them focus on "technical excellence" which is manager speak for "code quality". Here's what I've found: - Most companies don't actually care 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. - There are systemic challenges to code quality in these environments. Namely hiring practices, performance evaluation, and priorities (budget/timeline). Obvious. - Nobody can explain the benefit of code quality in terms persuasively enough to managers that they will accept the cost. I'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 "technical debt" either that or it's a tautology. There's an irrational lack of discipline in this area akin to credit card debt. - Furthermore, software itself does not matter to these companies. That last one is the most important and it is not meant to be normative. I'm not saying software is not of actual importance. I'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. 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. There are companies where the ratio of "business" people to IT is 1:3 and they balk when you tell them they're essentially a software company. "No, we're a mortgage company." Ok how's that working out? What I'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'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.
- user5994461 9y ago
  Give some names. That will tip out what stocks to buy long term and what not. I personally found that calling oneself a tech company is not a good predictor for good practices. Everything call themselves a tech company nowadays. You should certainly assess what kind of clients you're facing to adjust your recommendations. However, I don't think that the work environment matters as a short term consultant, whoever pays on time and has the biggest pocket is a good client.
jimjimjim 9y ago
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. please, for humanity, write documentation. even better if it's after the code is written. why does the payments-smart-broker have a direct connection to the translations database if it doesn't have a ui?
myf01d 9y ago
This is the second post from this website to get upvoted to the frontpage within 48 hours. I hope this is natural.
bryansum 9y ago
One huge problem is that there’s no context-indepedent definition of quality code, and criticisms often suffer from hindsight bias.
- bethly 9y ago
  This is why Sarah Mei's idea of Livable Code is so exciting to me: it talks about context-dependent quality code, and lets us talk about developing the context needed to move our definition of "quality code" to a more effective/more reliable/faster/faster-to-develop place.
bethly 9y ago
I've had business people tell me I should stop writing tests so I could go faster, even when I'm producing significantly more features than the developers around me who don'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. 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.
- D-Coder 9y ago
  "I've had business people tell me I should stop writing tests so I could go faster" Maybe tell them that double-entry bookkeeping doubles their workload and they could go faster with single-entry bookkeeping.
- sjellis 9y ago
  "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." This is the problem. Testing is not easy, and many developers simply aren't very proficient at it. Worse, we often don't recognise that it is a separate but important skill.
sseth 9y ago
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.

314 points by fodoj 9y ago

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

ataturk 9y ago
A big problem in the IT world today is that #1 is no longer the case--it is marketing departments that are driving a lot of software development and they don't care about standards, code quality, tests, anything. It's a bad culture change.
W0lf 9y ago
Yes, you summed up perfectly what I've been experiencing in my professional career for quite some time now.
carlmr 9y ago
So what is the prescription to find a company that doesn't check these 5 boxes?
- pjmlp 9y ago
  Start your own.
- crdoconnor 9y ago
  In general the companies that don't both A) pay better and B) are located in tech hubs / do remote work. So, go for more money, prefer remote or in a tech hub. You can also ask during interview about the coding experience of the manager you will report to. Usually they are up front about it. If you turn them down, do us all a favour and let the company know that was why (more coding managers and fewer MBAs please!). I'm not gonna lie, it's not going to be possible for everybody to avoid this kind of company, especially in the more backwater places. I left Singapore because I basically found one company that didn't obviously follow that pattern. They frustrated me too for other reasons so I didn't take their offer. I think that this is one of the most underrated reasons for the formation of technology hubs and one reason why Singapore, in spite of really trying to become a "silicon valley of asia" (VC money: check, money pumped into education: check, huge startup grants: check) just won't, and will bleed rather than attract talent.
  - petagonoral 9y ago
    > You can also ask during interview about the coding experience of the manager you will report to. Yes, for tech leadership. No for people management. Simply put, too many people in people management positions who were "technical" x years ago. This leads to them making technical decisions that their team should be making, which they absolutely should not be doing.
    - crdoconnor 9y ago
      >Yes, for tech leadership. No for people management. A good tech leader can handle people management too. A good "people management" leader can't handle tech. You want both. >Simply put, too many people in people management positions who were "technical" x years ago. This leads to them making technical decisions that their team should be making, which they absolutely should not be doing. Good tech managers will trust the judgement of their team and know when to give them agency and when to overrule them (there are sometimes legit reasons to do it).
maxxxxx 9y ago
In general I agree with your points. But you seem to have some gripes with "senior" engineers. I think if you left that out your points would be better. In the end it comes down to management not understanding the work and rewarding unproductive behavior. This has nothing to do with "junior" or "senior."
- l_t 9y ago
  While I haven't personally worked at such a company, I've observed some "toxic" workplaces and found that typically it is, in fact, the senior staff who are the biggest part of the problem. Only certain types of people achieve seniority in a toxic organization, and they are typically those who (deliberately or incidentally) benefit from the culture that everyone else hates. They build a clique and try to build influence while the new hires -- who actually care about doing things well -- turn over every 3 months. This is all anecdotal, of course, but I do think that in an engineering-hostile organization, the senior staff should typically take the brunt of the blame (just as in a successful organization they would take the lion's share of the credit).
  - maxxxxx 9y ago
    I guess that makes sense. If the org is dysfunctional the best people at some point will have left leaving the not so good people. But I think that change often has to come from management. Even if you are senior you often can't do much about stupid management other than leave.
- crdoconnor 9y ago
  It's not seniority per se (I count as senior), it's people with long tenure. If, as a developer, you've had a long tenure in an organization with bad code that's usually a bad sign.
ConceptJunkie 9y ago
I would add that management will gladly save an hour now, even if it costs 10 hours down the road. I'm getting really tired of the message from management of "Here's what we should do, here's why we should do it, and here's why we won't." In other words, they will periodically acknowledge that there are systemic and cultural problems that seriously need to be addressed, but consistently fail to address them.
ashelmire 9y ago
...wow, this is my organization to a T. Needless to say, it's time for a move upward and outward.
foobarrio 9y ago
I like this list. What I have found about point #4 is that even teams that try to actually measure performance in a meaningful way will miss things. If the quality of the software is slowing down feature releases, causing fires but is not being measured, you can make some headway with presenting ways to measure code quality so that your work shows up on their radar. This is difficult with such a subjective word as "quality" but tracking number of fires of time would be a good way to show that the way you develop is better than other people. The other thing that companies miss are employees that help other employees in a mentoring sort of way. These people essentially cast a buff on everyone they work with. These buffs can be in the form of better tools, improved workflows, recommending reading material, new technologies etc. Unfortunately it seems this is up to that person's superior to recognize their value and fend for that person to upper management. I feel like it's easy for me to identify peers that cast buffs but not sure how easy it would be for a manager to identify such characters.

navium 9y ago

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

marmaduke 9y ago
A clever quote saves us from having to think! (paraphrased from some original quote I can't remember)
- jacquesm 9y ago
  Yes, but in this case someone else did the thinking for you and it is actually pretty accurate. If the only time you care about quality is when you are being checked, audited or supervised then it will not work. Quality needs to be infused all across the board and needs to be reinforced from the management downwards throughout the whole organization, not just in the quality control department. So Ford was definitely on to something and beat mr. Demming by a couple of decades on that particular insight. It's no surprise that both of them had a lot of these insights in the automotive industry to begin with, where warranties can very rapidly eat up the profit margin on the sale.
  - marmaduke 9y ago
    isn’t this like saying quality code is code that is correct without unit tests? They seem unrelated
    - navium 9y ago
      Or more like, you write unit tests even if no one asked you to.
    - flynnieous 9y ago
      They are related in that quality code is code that is both correct now and can easily be made correct when things change--and things always change. Unit tests are what enable correctness in the future.

leibnizwasright 9y ago

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.

oldandtired 9y ago

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. If you can'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. Don'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. 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's problem. But remember that in your next job, you'll become the someone else.

Pica_soO 9y ago
If you dont get the time necessary- lie to your clueless superiors- tell the story about the complicated feature, that needs hours more- they will never understand how much a well made library will save them future time, so you are actually helping a clueless fool to do a good decision with that little lie.
- majewsky 9y ago
  It's sad that this gets downvoted, because it's the only realistic approach in such a situation (which is also sad).
  - leibnizwasright 9y ago
    Yes, I don't see this a problem, normally releases get delayed, if you get more time to develop better, then why not? I always saw testers talking with product owners and managers about one or other developer that was slower but had delivered less defect.
    - ConceptJunkie 9y ago
      I know that feeling. I'm one of those developers that is slower than a lot, but I also know from long experience that when I deliver something, it's solid. It's not that I don't make mistakes, but that I work in a way that helps to minimize them when I do make them. It takes me longer to get things done than the hotshots, but there will usually be fewer problems and the problems that do exist will usually be much shallower. And unlike a lot of people my work contributes to a net decrease of technical debt. I'm not saying this to brag, but to emphasize that this is what it takes to do quality work.

pgsandstrom 9y ago

> 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. Is it just me, or is less that four years not "really old"?

jacquesm 9y ago
The number of years a piece of software has been alive is not always a good indicator of how old it is. It can be 2 years old and in outright legacy territory. Some people are working hard to replace one legacy project with another. Software does not age well when it isn't constructed properly.
- jimmy1 9y ago
  In my opinion, when speaking of "legacy software", we should place a stronger emphasis on the actual meaning of the world legacy rather than the usual pejorative. Meaning that: this software has created a "legacy", in some form or fashion. Whether that legacy was it was used in the past to build the business, it paved the way for some standard or better practice, or it simply outlived it's time. Downvotes are usually reserved for when a comment is low quality or not relevant to the conversation at hand. Could you please explain if my comment fit into these categories for my own learning? Thank you.
  - eitland 9y ago
    Like it or not but legacy has taken a new meaning in software. I think it is Michael Feathers who defines it as code without tests in "Working Effectively With Legacy Code". (That said, I didn't downvote you and I'm also tired of the abuse of the downvote button. I think in your case they downvoted because it seemed like unproductive nitpicking.)
    - jacquesm 9y ago
      I like that definition. Maybe another one: code that nobody knows intimately.

dep_b 9y ago

You need to get the programmers together and agree on a coding guideline, a linter and other architectural fundamentals. 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. 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.

crdoconnor 9y ago
IME linting picks up about 99% fluff (ooh look there's some whitespace on a blank line) and 1% potential issues highlighted (usually minor). The reason people like to default to linting when "fixing code quality issues" is purely because it's 100% objective and measurable, not because it picks up the truly important issues. It doesn't. Edit: I am aware that coders have OCD impulses which can be sated with a linter, but priority #1 when fixing spaghetti code is unraveling the spaghetti, not sating your need to see }s in a place that makes you feel better.
- mathgeek 9y ago
  Most linters allow you to disable whitespace linting. Good tools allow you to learn to use them better.
- simonpantzare 9y ago
  I'd argue that there's a significant mental overhead reading code when it doesn't follow the same conventions, and that enforcing a style guide is a matter of having no broken windows. But of course there's no point trying to make shit look good.
  - dep_b 9y ago
    A linter and code conventions are a way to make code more consistent and easier to switch between. At times it becomes hard to see what code you wrote and what somebody else wrote, which is a good thing. If I open a file and everything "just feels wrong" but I can't change it because enforcing my personal preferences are just my personal preferences is just making things worse that really takes some valuable energy away I could use for actually improving things. But I can get used to a coding guideline that's not 100% my preference but a well enforced and consistent one. Knowing that if I fix indenting and naming the fix will not enrage someone else.

ataturk 9y ago

What the author is too young to realize is that there is no development path for him(?) as a programmer. Companies don't care if you have time off or hobbies, or a wife, or anything. They don't hardly give a shit that you need to breathe air.

tboyd47 9y ago

> Code review at the end of the task. This is something I still struggle with. I think it's a result of an open source tool (GitHub) bringing bits of culture along with it. 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. 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 "managed push" system instead of a "pull request" system. Edit: "Unfortunately, willingness to throw away work becomes a mark of pride at some places." 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.

detaro 9y ago
> Maybe enterprise projects need some kind of "managed push" system instead of a "pull request" system. What would you do different in "managed push"?
- tboyd47 9y ago
  Not sure? Maybe letting developers push directly to master, with an automated test run at each commit and a project manager or tech lead in charge of tagging and deploying releases?
pjc50 9y ago
> willingness to throw away work becomes a mark of pride at some places Is this a typo for "willingness"? Code review is important not just for preventing junk from entering the codebase but for ensuring that someone else has seen the thing and has some idea of how it works. I agree that "pull request" is the wrong terminology for a commercial environment.

swaqny 9y ago

hello https://www.hello123.com https://www.hello123.com

realworldview 9y ago

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.

jbrooksuk 9y ago

This is why I’m keen on automating code standards/quality away. We’ve recently launched JS, CSS and Vue.js support in https://StyleCI.io https://StyleCI.io to help more developers standardise their code.

trevyn 9y ago

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. 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. Thoughts?

JoeAltmaier 9y ago
I worked like that with a colleague of a decade in a startup environment - we produced tens of thousands of lines of embedded code in a year. It can work with a close understanding between the two people.
alextheparrot 9y ago
I see this often in a slightly different context - people who write libraries well and people who write application code well. One tends to be generalized, focused on end-user ease of use, while the other is first and foremost attempting to achieve business goals with the available tools.
hinkley 9y ago
Eventually you feel like a janitor or a babysitter. The problem is that the guy making the mess gets credit for things and the guy cleaning it up keeps bad things from happening because of him. If your boss is not just the right type then you will become the bus tribute.
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
hindsightbias 9y ago
There used to be a time where every new coder spent a couple of years learning/maintaining their elders' code - fixing bugs, porting, optimizing, learning about how the environment(s) integrated. The concept of journeyman in sw was a thing, and mgmt/team expectations from the youts was appropriately gated. Now it's different (outside of HW orgs), but as I look out a decade or so, I'd rather have a part-time retirement job "cleaning up" interesting projects than travel/consulting.

ComputerGuru 9y ago

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 (//mqudsi: this is an ugly hack because I was too lazy to clean up access to this global variable. Fix me.) 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. 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 right ten lines of code then whatever else I could have or would have written or accomplished in those 17 hours doesn’t matter. 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.

ionforce 9y ago
> I place a premium I think the problem is are you saying this as an individual or are you saying this as someone in leadership with power. Place a premium all you want. But if you're a grunt, that opinion is going straight to dev null.
- laythea 9y ago
  I laughed at this :)
LrnByTeach 9y ago
carpenter 2,000 years a very good analogy with quality of code. This is very good reward system for developers . placing a premium on “skills learned or perfected” over “bugs closed or features implemented” > 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. > 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.

ManlyBread 9y ago

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.

Terr_ 9y ago
I'm in a similar situation right now: The company thinks that any feature-wanter who's loud enough is automatically "one of the product owners" (always plural, always ambiguous) with the ability to tap an outsourced development house for "additional capacity." I regularly come across months-old new code that the main team wasn't even consulted about. Reinvented caching layers, eval'ed code in database tables, file-download endpoints that accept any path from the browser, and code with so many immediate red marks that the writer can't possibly have been using an IDE. It hurts my pride that I've been here for years and can't seem to change the pattern, but perhaps at some level it's basically codependence [0] and I have to leave the sick corporate-entity until they really "want to change." [0] https://en.wikipedia.org/wiki/Codependency https://en.wikipedia.org/wiki/Codependency
- SIRHAMY 9y ago
  At that point, you could probably bring in Legal. Not only are these just poor coding practices, but some of these things are very serious security vulnerabilities. If you've got contracts with clients, or even if you're licensed straight to individuals, it's a good bet that you're breaching some data security/privacy rules. Legal would definitely want to know and take steps to correct.

logfromblammo 9y ago

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

justin_oaks 9y ago
Every company I've worked at will ship version 1 to production and proceed to build on top of version 1 forever. Of course, by version 1 I mean "the proof of concept I showed someone else".
- logfromblammo 9y ago
  A log can dream, can't it? It's the classic bait-and-switch of corporate development. They get you in the door by pretending they have a rational process, and wait until you're invested before dropping the facade. I, too, have never worked for a company that ever considered retiring software ahead of immediate necessity. Generally, it's always "we don't have time to do it right in the first place, because we're too busy fixing all the stuff that is broken right now."

deleted 9y ago

[deleted]

Ocerge 9y ago

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't really my responsibility at the time. I'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.

taeric 9y ago

The largest burden to raising code quality I have ever seen is the conflicting burden of maintaining product quality. 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. 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's intrinsic quality. Instead, they are trying to use the product. If you can'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. 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't punish your users, but don'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.

mempko 9y ago

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

ryanmarsh 9y ago

I am a Dev Coach. This means companies hire me to pair program with their developers and help them focus on "technical excellence" which is manager speak for "code quality". Here's what I've found: - Most companies don't actually care 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. - There are systemic challenges to code quality in these environments. Namely hiring practices, performance evaluation, and priorities (budget/timeline). Obvious. - Nobody can explain the benefit of code quality in terms persuasively enough to managers that they will accept the cost. I'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 "technical debt" either that or it's a tautology. There's an irrational lack of discipline in this area akin to credit card debt. - Furthermore, software itself does not matter to these companies. That last one is the most important and it is not meant to be normative. I'm not saying software is not of actual importance. I'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. 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. There are companies where the ratio of "business" people to IT is 1:3 and they balk when you tell them they're essentially a software company. "No, we're a mortgage company." Ok how's that working out? What I'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'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.

user5994461 9y ago
Give some names. That will tip out what stocks to buy long term and what not. I personally found that calling oneself a tech company is not a good predictor for good practices. Everything call themselves a tech company nowadays. You should certainly assess what kind of clients you're facing to adjust your recommendations. However, I don't think that the work environment matters as a short term consultant, whoever pays on time and has the biggest pocket is a good client.

jimjimjim 9y ago

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. please, for humanity, write documentation. even better if it's after the code is written. why does the payments-smart-broker have a direct connection to the translations database if it doesn't have a ui?

myf01d 9y ago

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

bryansum 9y ago

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

bethly 9y ago
This is why Sarah Mei's idea of Livable Code is so exciting to me: it talks about context-dependent quality code, and lets us talk about developing the context needed to move our definition of "quality code" to a more effective/more reliable/faster/faster-to-develop place.

bethly 9y ago

I've had business people tell me I should stop writing tests so I could go faster, even when I'm producing significantly more features than the developers around me who don'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. 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.

D-Coder 9y ago
"I've had business people tell me I should stop writing tests so I could go faster" Maybe tell them that double-entry bookkeeping doubles their workload and they could go faster with single-entry bookkeeping.
sjellis 9y ago
"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." This is the problem. Testing is not easy, and many developers simply aren't very proficient at it. Worse, we often don't recognise that it is a separate but important skill.

sseth 9y ago

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.