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.
It can be very frustrating, but ultimately it's a reflection on you.
Whether you're a coder, or a librarian, or a janitor, take pride in your work. Do the best job you can.
If everyone else's code looks like crap, that's on them. When new people come on, they'll see your work compared to the slackers, and start emulating you, not them.
Like anything in life: Do the right thing, even when you're surrounded by villains.
Better advice: Go to where they actually care about what you're doing, if you can. Otherwise, put effort into what you're doing, but don't go overboard, and absolutely never work overtime.
Those places are basically unicorns, as far as I can tell. I have my own anecdotes, of course, and they oscillate between "we cared about code quality" and "we didn't have time." My experiences and the conversations I've had with others lead me to the conclusion that: almost all of us have deadlines that we didn't really help set, that we're always struggling to meet those deadlines, and that there is a stupid amount of money on the line that drives these decisions. And, so it goes, "get it done and ship it yesterday" is the commonality that I see.
That said, despite the frustration, I do try to hold myself accountable for writing clear and concise code as much as I possibly can and off-setting the times when I have to commit some clever hack with long-form narrative style comments.
I've also seen the opposite happen as well where endless feedback and getting the "perfect" architecture has almost sunk a few teams. If you take too long building the ivory tower then the market may move past you.
The thing I care about is if it's a deliberate decision made with consideration of the rest of the business of if it's driven by fear/reactionary/habit.
The former usually means that you'll try and budget in time after the crisis to fix it up, the latter tends to spiral into a complete mess that no one wants to touch after a certain amount of time has passed.
Any team striving for a perfect architecture rather than building something that works and then seeing where the bottlenecks are isn't focused on "code quality": they are ignoring best practice in favor of intellectual satisfaction. The best software architecture is any architecture that solves the problem.
Yeah, there's a natural tension in this. I know I tend to wander towards the "ship it" category but yet I've found my best work was when I was paired with someone on the "correctness" side of the equation.
It forces a constant re-evaluation of your methods and reasoning on both sides which leads to something even better than the two individual approaches.
Not sure why there's a hard-no on working overtime. Not everyone finds value or fulfillment in the same way or has the same goals.
My cousin just went from being an intern at Tesla to a FTE. This group change entailed going from 11-12 hour days to 9-10 hour days. It's crazy and maybe not for everyone but he's happy there.
I work at a more chill company, but sometimes there's something I want to do on the company code base that is not asked for by any stakeholders. I'm happy to occasionally put in an extra 10% to do something that scratches my own itch. I don't see much difference between this and someone who goes home and works in their garden or plays with Arduino or tinkers on an old car.
Working overtime? It happens. I accept it as part of the job, as long as it's rare.
Working overtime to clean up other peoples' mess that nobody else cares about cleaning up? Hard no.
If it floats your boat, if it's a hobby to you, if you want to spend your free time on it, then sure, knock yourself out. Have fun. Feeling like you have to? No.
I get where you're coming from. I just did this the other day (worked through the night on something for someone else over the weekend) but I may not have if I knew someone was going to come behind me and blow it away.
Maybe what I learned from it alone would be worth the effort. Tough to say.
A contrary opinion based on experience - instead of focusing so much on how bad the code is take the time to get to know your coworkers better. Talk with your manager and the business leaders about the business. Learn more about the business you are in and how your code makes an impact to that business. At the end of the day the goal is not to produce clean code. It's to make your company successful.
I'm not saying code quality doesn't matter, of course it does. But there is a bigger picture and if you don't take the time to become a part of that you will not be very relevant.
Yes it is good to understand people and the business, but you are also hinting that much of the bad code around the place is some kind of big-picture smart optimum of technical debt. vs. development velocity.
But this is unlikely if you stop to think about how humans behave. Who in an organisation has an incentive to find such an optimum? Shareholders and the board maybe; but they can only drive things by rewarding and punishing middle-level individuals. And they can only reward impact that they can see. Thus the incentives are to create visible impact which can be spun as a net gain. If that creates technical debt, then that is somebody else's problem.
Yep, this is difficult, but I think it is the correct approach. To follow on: if you do this successfully and you also demonstrate technical value to the organization, you are very likely to find yourself with enough credibility to successfully advocate for (or lead) efforts toward better engineering practices.
If you do all this, and never gain that credibility, possibly due to problematic individuals at the higher levels of the organization (which you can't control), then it's probably time to move on.
I agree, but it seems to me that being dragged down by technical debt is massively more common in our industry than missing important deals because of excessive emphasis on clean code?
Our industry is pretty hilarious in this sense. In school, it's expected that you go through multiple drafts to complete an essay, and usually those who skipped that process paid a penalty. Publishing is a high speed industry, but time is still set aside for revisions and editing. These same standards seem to rarely be applied in programming, I guess because our work isn't seen as writing communication. We make computers "go". Because of that, we are too often writing and reading each others' rough drafts.
Especially in a startup, but obviously in established companies as well, this will give you an idea of where it’s all headed.
If you’re in a place that’s reliant on good code (and good execution strategies) to exist, and the other people don’t or won’t or can’t really grasp the magnitude of what good code means to the company - leave.
> At the end of the day the goal is not to produce clean code. It's to make your company successful.
An even more accurate description: don't assume anything, determine what the goals of the power player employees at the company are, and follow their lead. Assumptions of doing a good job, helping the business, fulfilling the mission statement all seem like reasonable goals, but assuming you are working in a reasonable organization is not always a safe one. Sometimes, the whole thing is mostly smoke and mirrors, and someone coming along with the aim of doing a good job will become very unpopular.
If you happen to find yourself in one of these places, just imagine yourself on the set of a TV series about an IT department, say all the right things, and you might very well be able to get paid to play around with things that interest you 90% of the time while keeping up appearances with your other 10%. Be mindful of what this can do to your resume and skillset, but as long as you're making productive use of your time learning new technology, you can typically lie about what you did at your last job and most interviewers won't have a clue anyways.
"Like anything in life: Do the right thing, even when you're surrounded by villains."
That's a tiring way to live life too. If you're surrounded by villains, you should try to leave and go to a place where doing the right thing is easy. If at all possible.
Strongly agree. Still, do keep some of your powder dry and look for opportunities to join a better team or company.
An engineer once told me he cried with joy when he saw the interface and used some subsystem I had written a year earlier (in C, for an embedded system). So, I encourage you to write such great, beautiful code that other engineers will cry with joy when they behold and maintain it.
I definitely do the best I can, but as someone sort of in this position I worry that I'm becoming a worse programmer for it.
I'm junior enough that I often don't know what to do. I've never gotten really good at full unit testing for example. I really do think in situations like this my best bet is trying to find somewhere where they follow better practices.
Imitation is the best form of flattery but you can also be proactive in your learning how to write better. Read code that's open-source and solves similar issues for a similar case in the same tech stack. Understand the architecture and conventions. Understand where the codebase has areas for improvement.
Before you learn about types of hammers and nails learn when to use which one.
The problem with more senior people is that they can lack the time and motivation to teach you so until you don't own the problem yourself pushing it to "ppl don't want to teach me :(" will not do anything.
Also, practice makes perfect and good coding practices tend to be somewhat universal.
> High standards for workmanship and worker safety are luxuries, but even some people who have the benefit of access to good training and safe workplaces don't take advantage of them. You shouldn't be ashamed of striving for the highest quality work you can do — instead, be thankful that you know what to strive for, and pass on your craftsmanship to anyone who is willing to learn.
That's all well and good, but what if delivering good code actually necessitates a pretty large shift in the codebase? Usually that requires buy-in from teammates because it will take substantially longer.
Almost always the answer will be no. So you're forced in a way to ship bad code.
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."
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.
> but some of these things are very serious security vulnerabilities.
That's a very good reason to bring in your Security Officer or a similar compliance officer; its probably not a good reason to go straight from dev to Legal.
Quality code is it's own reward. Yes, clean code is more fun to write and work with. But, just think of it as a different kind of optimization problem. If the investment is not going to pay off in the future, then it's not worth doing in the first place.
PS: This is not giving up, it's about getting even better by becoming ever more flexible.
Don't assume I am talking about personal ROI. Team ROI is critical. Seeing a feature early so we can decide if the goal needs to be changed it valuable. Clean code that's going to be deleted tomorrow is not.
The 3rd time you touch a function is often a great time to make it awesome. However, a lot of code never reaches production and maintainability is more of an issue for code that survives.
I don't think the parent was talking about writing bad code. I think he/she was saying not to stress about writing good code too much. Those are different things.
This is why you want to do some work in the interviewing steps to see if the company you're considering has a culture of code quality and mature engineering processes. "What do you need to do to release code?" "Do you do code reviews?" "How do you set aside time for refactoring?" and so forth
It's not a tradeoff. The reason we like quality code is it saves time in the long run by being clear, easy to change, less error-prone, etc. If you expect to be employed in 6 months, you should be refactoring and putting care into the quality of your code. It's hard at first, but I'm at a point where I'm the most productive engineer and I work the least amount of hours - because my code is there to help me, not hurt me.
I've seen a lot of well-intentioned code refactoring that made the code objectively worse. Refactoring well takes a pretty seasoned programmer to do it.
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.
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.
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.
This is absolutely the situation I am in right now, and I desperately need all the guidance I can get. We’re talking thousands of lines of React components that rely regularly on manipulating global js variables, mixed with MVC 5 written in Razor delivering variables in script tags, mixed with outdated jQuery, that’s all just concat’d together with gulp and that hasn’t seen a refactor in years of changing hands with no style guide. The company started in 2004 and I swear some of this code is still floating around from the day it started. We have three sets of scss breakpoints, three or four layers of “common.scss” files that act like a piece of furniture that has been painted over dozens of time (with shit like * {padding:5px} floating around), and an unknown amount of dead code. There’s lines written back-to-back with vastly different styles (with a random distribution of semi-colons and arrow functions and etc), and major global variables named with misspellings. And while I clean this all up, I am expected to continue pushing out features and addressing serious bugs with stop-gap measures.
Welcome to code development in the real world 101.
You either go insane, give up and take up beekeeping, start your own company or finally decide to not give a shit anymore and start hacking the same way as everybody else because in the end your are not sending astronauts to Mars, and it works "most of the time" is good enough for the clients and the price and time they are willing to pay.
You need to tell your manager that it's simply impossible to both clean all that up and also make progress on the project. You need to stop the erosion in order to fix it; fixing will require fundamental changes that will absolutely block progress. If aren't able to freeze the project, your cleanup progress will be constantly thwarted by new ugly hacks.
There's just no way around it. If your managers won't freeze the project until you make meaningful progress, you're going to be stuck working with this ugly code for a long time. Try to convince them that in the long-term a cleanup will pay dividends. Without their support though, you won't get anywhere.
If you're able to freeze the code for a bit, it sounds like it might just be quicker to rewrite some parts like the CSS. Don't take on the whole project at once - find pieces that can be rewritten individually, even if it's a large part like all the styling.
I disagree with most of this comment, but I think it's an interesting and valuable discussion.
Here's where we agree: You need to stop the erosion in order to fix it. Every developer on the project needs a shared vision of what "better" means. For example, the parent comment mentions React components that manipulate global variables. First of all, everyone agrees to stop doing that, and agrees on the alternative (use props, a redux store, whatever).
But you don't stop the world and rewrite to the new standard. Instead, you apply a strong "boy scout rule" to every code change. If a developer modifies a small component, they also need to remove the global references. If the existing component is large, the developer must extract a smaller one, and the new extracted component must meet the new standard.
This will slow your velocity - at first, by a lot. But you never stop delivering entirely. You never waste time rewriting things that you would never touch again anyway. You also learn along the way - because while "don't use globals" is pretty universal, most architectural decisions are not. You will find that the "clean new standard" changes to match your application. At the same time, everyone on the team learns about the new standard, and buys in to the new way of doing things. There isn't a "new system" with the cool kids, while the B-team strings along the old one and waits to be laid off.
I've mixed feelings on this still. It leads to big code reviews, with most of the changes being less important. So I rather like the separation, spend some time just for cleanup. Maybe take notes on wins as you see them but you don't need to do them yet (or put them in the same review as another bug fix / story item).
If you're using git and can separate things out cleanly then I think fixing it as you go would work better. I yearn to use git every day again...
Well, I'm not talking about a major refactor (squash them when you see them). This should be an enum, this is named poorly, this variable is scoped wrong, inline sql when should be a sproc, that kinda stuff. A few lines a fix, the low hanging fruit.
Major refactors certainly need to be accounted for in a sprint(s), but keep features a priority when needed in sprints.
Unfortunately there are business reasons why freezing the code is impossible. We’re ecommerce and working on a timeline dictated by consumer behavior. So if we need a promo tomorrow it’s going live or else we’re not making budget. I kind of assume this is how we got into this state to begin with.
And unfortunately nothing will change because what you want to do is better in every single way, but their way of doing thing is better in the only one that actually counts: It's faster and cheaper.
My assumption is that I will never clean up this entire codebase. Rather, I’m looking for the best way to triage the situation: what are the things I can/should try to fix first?
Make a list and organize all the things you'd want to change. Untangling balls of mud often take on the order of months to start seeing any kind of progress. You have to make sure you keep things organized over a long time otherwise you can't tell whether or not you are making progress.
If a module breaks often when seemingly unrelated things change or breaks every time someone touches it it's easy to say the module is badly written. It's often hard to say why it's bad and harder to say how to fix it. However at least you will have data and be able to defend your position that messy code in a particular module actually slowed down the addition of a new business features.
If you are using a bug tracking tool (Jira, Bugzilla etc) make a bunch of private ones for yourself. If management doesn't like all your private tasks showing up on reports then try to get a section for yourself or see if you can deploy your own "private" bug tracking instance.
Any time you encounter a problem make a bug for it even if you have no solution. If upgrading a library version a minor version causes a break make a bug for it etc. You'll start to see patterns and then you can make small but really important surgery on the code. You can have a plan for how to fix a particular module when the time arises.
For example we had a core module with some 190 downstream internal clients across some 5 different dev teams. A recent Oracle version upgrade caused problems because we would have to to coordinate everyone to update at the same time. I already had a long time standing issue that the module is poorly organized and already had a list of all the things that were wrong with it. When this issue came up I immediately stepped in and how to completely remove Oracle from the core module so that the downstream clients can each upgrade on their own time. Because I had thought about this for time I was ready to defend the proposal by showing it would take less time to do this. I was able to do a refactoring I've been wanting to do. Over time people will start to listen to you more if you are actually delivering shit on time. Otherwise, even if your complaints are correct, you will be labelled as just a whiner.
Write down everything you know about the codebase. Whenever you discover a surprising dependency or behavior make a note of it. This is something you can do in passing as you push features.
At some point you'll start recognizing structures in the code some of which will be small enough to surgically improve.
How will you make sure that you are not introducing regressions in such code base? You cannot add unit tests because it is probably untestable mess. So instead of some uncertain dividends, which may or may not materialize, you introduce real risk of breaking already existing stuff.
For "light reading" on this subject, try _Working Effectively With Legacy Code_ by Michael Feathers. We used it to very good effect at my last company.
Personally I thrive in this kind of environment, it's a kind of comfortable chaos. MVC5 is positively modern compared to many of the products I've worked with which have included (within the last 5 years) VB6 winforms but mostly aspx webforms.
Understand that previous developers might not know what a DOM is have likely written ad-hoc jquery snippets, included 3 different versions of jquery-ui until they happened across the right combinations of versions to get their plugins to play and will have a mentality of "it was working".
Given that, here's some advise on how to stay sane:
1. Read and "Digest Working Effectively with Legacy Code" but accept you'll likely not be empowered to actually implement the changes.
2. Understand you'll have a grace period of ~6 months where you'll be far more empowered to make changes and get suggestions pushed through, after which you'll likely find yourself worn down by the system and more accepting of the status-quo. Leverage this time if you can.
3. Try to identify what caused the product to get to the state it is so it can be avoided for future products. If it's something you're not empowered to change such as "bad hiring policy" try to work out how you can spot that in future interviews.
4. Be pro-active in looking for bugs, particularly security flaws. Finding an IDOR which lets you get cross-account data is usually fairly straightforward in these kinds of environments. Doing so gets you noticed so you're not just another cog in the system and can provide real value. Be careful not to put others' out too much while doing this. It sounds like you only work on the front-end but even what appears to be front-end can have security implications such as template-injection.
5. Draw a line in the sand. Be entire accepting in legacy code but if someone is working on a new part of the product or is fixing a bug in legacy code be absolutely ruthless in what you'll let passed in code review. This may not do you any favours socially but a reputation for harsh code reviews isn't all bad. For one thing you'll have to do fewer code reviews.
6. Don't bite off more than you can chew. Treat it like a giant knot and don't be tempted to pull at threads unless absolutely necessary. Instead wait until given strong reasons for refactoring.
In regards to #5, worth pointing out that some coworkers are probably just as disappointed with the current state of affairs as you. They would probably really appreciate somebody pushing them to hone their craft.
Also worth considering that some people never learned how to handle constructive criticism and will take any suggestions as personal attacks. Stay as far away from these people as possible, you aren't going to change them but their pettiness can make your life miserable, particularly if they're closer to management than you are.
It shoud be stressed that a developer should not assume all his predecessors were wrong just because he doesn't understand why some stuff ended up being the way it is.
The world is packed with developers who proud themselves of fixing things that were never broken, and in the process break stuff.
> if someone is working on a new part of the product or is fixing a bug in legacy code be absolutely ruthless in what you'll let passed in code review. This may not do you any favours socially but a reputation for harsh code reviews isn't all bad.
In my experience this is the most important thing. I particularly focus on the "what the heck does this code even do" aspect - the person who is modifying the code needs to be able to explain exactly what the code does and why it is correct (don't accept "it compiles and the one unit test we have passes"). Forcing the team to understand the code will make it very difficult for them to continue adding bad code to the pile, as they won't be able to explain what they bad code does, or will realize the code is bad in the course of trying to explain it.
It is very, very important in this situation, however, to not be outright mean. Do not let anything through that you would not be comfortable maintaining, but don't be a dick about it. All that will end up accomplishing is that you'll be blamed for things not going through, and then you'll lose your credibility as steward of the code. People will go over your head to the boss, who will just make you pass it.
You should trust your engineering judgement, and your tech lead should listen to you when you raise these issues, and your product team should give your team engineering time to start cleaning things up. If any of this doesn't happen, get a different job.
As engineers we have a responsibility to raise concerns about bad practices and projects that have been neglected this way. Doctors raise concerns about hospitals, lawyers raise concerns about firms and enterprises, structural engineers raise concerns about buildings and infrastructure. Software engineers should do the same, resigning in protest if need be.
First agree on what it should actually be and document that. Make sure nobody commits anything that makes the codebase worse. Don’t refactor but clean first, and only while delivering value.
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.
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.
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.
At times it becomes hard to see what code you wrote and what somebody else wrote, which is a good thing.
I suspect this is the big point of disagreement between lint-advocates and many of those who are dubious. I generally don’t see big wins from collectivising code, and on the who prefer to treat people I’m working with as individuals who can be interacted with 1:1 vs an amorphous “the team” writing “the codebase”.
Usually there’s a style that’s mandated by large authorities like C# formatting is mandated by Microsoft and JetBrains. Copying their style gets you there for 80%. The rest is whatever you agree on and usually not something that bothers me.
If you’re the guy that thinks having a 300 line function in an 8000 line class is just an individual way of expressing yourself you’ll have to fight me.
If you think real tabs is better than 4 spaces I shrug and let you have it your way.
The fact that you’ve named an IDE vendor rather emphasises that there is a substantial gray area. By no means everyone wants to use an IDE (let alone that specific one...)
True. But for Objective-C I often used the NY Times style guide. Just whatever the one is that is the most complete and most easy to maintain really. But I notice with C# that if I copy-paste reasonably fresh code from Stack Overflow to VS + RS I sometimes get zero warnings because the other programmer uses exactly the same toolchain and style. Same goes for Python PEP8 in PyCharm. Personally I like the idea of having a strong similarity in code style within an ecosystem, especially when dealing with libraries that more or less follow the same conventions as the code that I wrote myself.
We did that (rubocop). Lots of fluff, a dozen or three minor to medium issues, and a couple of downright critical ones that slipped through production cracks out of sheer luck. Not even counting the last ones, the holistic effect of having a code base normalized is unmeasurable (i.e == through the roof), because suddenly moving from one part of the code to another is consistent enough that it removes a mental barrier to seeing patterns and enabling refactoring.
IMO there are two features which linting tools need before I can start treating them as serious "necessities" on a code base rather than "nice to haves".
lint [cosmetic | medium | serious]
- you must select one to run the tool, and the rule defaults must be sensible. No "100 character line length" in 'medium'. That's strictly cosmetic. Serious is for initialized and unused variables and the like - things which you might plausibly say "I'm not unhappy that broke the build because it could have indicated a bug".
lint medium --against=branch
- the linting tool should be able to intelligently compare against a baseline branch and only warn you about issues on code you have actually touched.
I do not agree that the holistic effect of having a code base "normalized" is "through the roof". I think the cost is relatively high while the benefits are relatively low. Right now at work if I run a linter against my code there are about 10,000 "issues" - the top 50 of which are completely cosmetic and I'd be remiss to invest time in fixing them.
I'm not opposed to linters on principle and I do use them, I just think that there's almost always bigger fish to fry.
A lot of cosmetic rules can be fixed automatically (e.g. `eslint --fix`). In that case the cost of having them on is near-zero, so even though the benefits are pretty mild the ROI is still positive.
I agree, linting doesn't pick up much. But, at places I've worked where the codebase was kept linted, the humans did a better job of catching bugs in code review.
My guess is that, when you have a cosmetically messy code base, people start to develop a lower standard for what counts a understanding the code they're reading. Probably as a self-preservation mechanism. There's only so much time in a day.
Also: if your coworkers care enough about quality to add and maintain a linter, they're the kind of coworkers that care to do good code-reviews and maintain a high quality bar.
"IME linting picks up about 99% fluff (ooh look there's some whitespace on a blank line) and 1% potential issues highlighted (usually minor)."
What language are you using? Dynamic languages are fairly difficult to meaningfully lint because it's hard enough just to analyze a function for problems, let alone extend past that. Static languages are easier to write non-trivial linters for, because there's more information just sitting there in the source, waiting for something to grab it.
But even for dynamic languages, linters can still do things like enforce documentation standards, code testing/coverage standards, and some other basics that may sound trivial, but still add up to very useful things.
I find luacheck (a linter for Lua) invaluable for picking up typos, unused variables, variables shadowing other variables and unintentional global use (since Lua defaults to global by default). The types of checks seems mostly reasonable to me [1][2].
"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."
I think that ideally, linting and especially formatting help quality by taking the trivial issues off the table. If your code is currently "clean", and the tools reformat or flag the code that you just wrote, then hopefully those issues will never be committed into the repository, so human code review can be about substantive points.
Great advice here. Agree on a process. Do it slowly.
I work with a lot of legacy code and have felt overwhelmed at times by all the different coding styles that have been used through the code base and not know when to refactor or simply clean up.
Over the last year or two I've been using a linter to help me with all this. Basically any code I touch gets cleaned to the point the linter isn't complaining. This is usually a fairly quick and fun process and I've actually learned a lot along the way.
I would refactor as soon as too many things were touching and the code started to have a smell about it even though the linter wasn't complaining.
It has made maintaining legacy code more fun (almost like a game) and given me some better practices when moving into new code.
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.
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.
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."
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).
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.
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.
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.
> 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.
>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).
Happy productive teams are teams which have a tech lead making tech choices (& involving team to some extent), with the people management side taken care of by a (dedicated) people manager who can cut across multiple teams ( & also taking care of the people management of the tech lead)
> 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"?
There is a real difference between a properly maintained, up-to-date project that happened to be started four years ago, and a project that was started four years ago, has never seen any dependencies update (not even security fixes), and is dirty hack over dirty hack.
By the tone of the article, the author is clearly talking about the second kind.
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.
I've - unfortunately - seen a case like that a couple of weeks ago. Very sad, moreso because they did not realize they were simply replaying the past. With all the best intentions of course.
My company is hiring a company for the 5th or so time to outsource IT to this new wonder app that will replace us. It's being built in Cold Fusion. Lmfao, 22 years old out of the gate.
So far they're about 2-3m in trying to replace us. Never gets far. Worst managed company I've ever seen. And as a consultant/contractor for 25+ years I've seen a lot of horribly run companies.
I'm joking. I would not start a new project in Classic ASP in 2003, much less 2018.
I did like it back in the day though and it was still a better choice than .Net 1.0. .Net 1.1 was okay, by 2.0 it was pretty decent. 4.0 beyond is fantastic IMO. I'm a bit of an MS fan though. I like their tools.
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.
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.)
Oh I know, that's why I am rebelling! I think words mean very specific things. I know it may seem like unproductive nitpicking, but in my experience the hundreds of discussions I have witnessed and been a part of myself in discussing legacy systems, bringing the pejorative version of the term to the table usually hinders the discussion more than anything, and it is this attitude that greatly contributes to the "software is eating the world" problem we soon to experience with everyone recreating the same library every day instead of reusing existing, proven solutions -- talk about unproductive!
"Back in my day", legacy systems were admired! I mean, heck, they were still there because some team(s) were using them every day, more often than not, they were there because they made money.
As one famous software engineer once said, "'Legacy code' often differs from its suggested alternative by actually working and scaling."
NASA was reusing code written from the 70's all the way up to 2011! Surely there is something in this wonderful land of legacy code that is worth saving? Or how about our operating systems? Full of wonderfully working legacy software that might just need a touch of love, rather than the usual thrashing of "how stupid those other devs were" and a total rewrite, which is what usually happens sadly.
In any case, I think another poster may have touched on it, I think we as engineers should try to refrain from flippantly labeling anything that is essentially "old" (where "old" might be 6 months, 2 years, or 10 depending on the organization) as the pejorative form of "legacy software", and just call it what it is -- bad software, some of which may also be legacy to your organization. But the conflation of the two terms is not helpful and adding to the confusion.
I've worked on old but very well maintained code that could easily go another two decades or more. Probably the original writers have long departed this world. But what they put together was put together with either incredible forethought or impeccably kept up-to-date. It was hard to tell which because this stuff was built before the age of version control, which gives you a bit of an idea how old it was. I would consider that 'mature' code, but not necessarily legacy.
Legacy code to me is code that has become hard or even impossible to maintain. Code that people avoid working on, not because it works, but because they are afraid of it.
Sure there are still lessons to be learned from such code, and you will learn those lessons the hard way if you have the temerity to mess with it. But every now and then someone is tasked with fixing a bug or adding a feature that can no longer be avoided and the send-offs are comparable to talking for the last time to people that are about to descend into a mine or something to that effect. Everybody knows there is a good chance we won't be seeing them again for the near future, if the axe of demotivation doesn't cull them from our ranks.
I've always known it as software that exists and is actively being rewritten, so a mainframe system would be the legacy system while writing a new Windows application to replace it.
Of course it's not really old. Though in my experience age has only a loose correlation to overall code quality. Some really old programs were well architected to start and have been carefully maintained. OTOH, I've worked with devs who are one-person technical debt factories, and allowed to work on relatively young and sparse applications will quickly make it an unmaintainable monstrosity.
My lab has a tool which has been actively maintained for 10 years and has a full-time employee supporting it and a related follow-up from 3 years later.
It takes a lot of effort to keep cross-platform support while continuously improving it. Granted, not every project deserves that kind of effort, but I respect the effort it takes to keep software up-to-date.
Funny how no one has any meaningful advice, just some snark about those dang young developers. Get off my lawn!
That line wasn't the important part of this post. This one was:
> You should also have a global self-development plan. If you can’t put it into practice under the scope of the project, you should spend your free time on it.
Damn straight.
If you work somewhere with tight deadlines and rubbish code quality, and you're just sucking it up and writing rubbish code, you're part of the problem.
You should always have a plan about how to become a better more effective developer where ever you end up working. Sometimes that means plan to spend 10 minutes a day talking to your project manager. Maybe review code the last 1/2 hour of the day. Maybe make some internal tools to help automate your job.
Don't just sit there and be miserable; if your job/company sucks and you can't find a way to change it, at the very least make it a stepping stone to something better.
Some idle advice from my experiences working in places which sucked:
- If you write code, it should be good code. Even if other code is bad, that's no excuse to stop caring.
- ...but, you dont need to refactor that. Just do what you have to do, and make it as good as it can be under the circumstances. Don't break other things when you make things cleaner and better; that makes PMs think that 'good code' = 'break features'. Disaster.
- If you ship rubbish to 'come back and fix later', you'll never come back and fix it.
- Don't just comment out code and replace it a quick fix. Don't [Ignore] failing tests. If code is going away, take responsibility of actually delete it.
- Don't leave 'TODOs' in your code; either do it, or don't. No one is ever going come back and do your TODO. Not even you. That's what issue trackers are for.
- Some developers don't like running with 'trainer wheels' or 'guard rails' as they refer to unit tests. Ignore these people. Always write tests. The worse the place you work is, the more desperately you need those tests.
- Project managers (unless utterly incompetent) don't care about deliverables per se; they care about managing expectations. Estimate. Review your estimates. Try to deliver on your estimates.
- Don't work overtime unless it'll actually make a tangible difference for a specific deadline. :)
I would change the last point to: Don't work overtime unless you, personally, get something out of it. That something might be not getting fired. But if it doesn't get you anything... Don't do it.
I think it actually originated in 2002 and those are junk left over from the use of Rational Rose code generation. Revision history only goes back to 2007.
Perhaps a former programmer deleted the revision history when they were about to move into a management role at your organization. I once stumbled upon a manager's name in the history of a 1970's Cobol program which had a goto statement every 5 lines, and it usually took half a day to make a simple change. All of the other similar-looking programs had had their history purged. When I showed the history notation to the manager, the look on his face wasn't nostalgia but fear.
That is barely out of adolescence. Part of my day job is shepherding a large legacy web application into final retirement. 18 years and still trundling on, longer if you count the desktop applications that came before in the product line. Still getting new development time allocated to it too, most recently implementing improvements to help the clients comply fully with GDPR. Traced a problem in production back to a bug introduced 13 years ago just the other day...
I worked on code that had been in active development for sixteen years, but it only got to be sixteen-year-old code because it was reasonably well-written and maintained. Code quality and developer skill is what lets software become older than four years old without collapsing under its own weight.
That seems pretty fresh to me, but I may just be jaded: I'm working with a mission-critical PHP project with portions -- including fossilized third-party libraries -- fossilized since 2009.
It's just that the javascript language, frameworks and ecosystems have seen massive changes over the last couple of years. C for example hasn't seen this change. So yeah, C code from 5 years ago would look the same if written today, while javascript of just 2 year old might seem outdated.
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.
What I don't like in "commercial" code reviews is that most reported issues are there just to fill space. It's busy work. There is this formal comment system. So instead of fixing this typo in a code comment directly reviewer writes a comment. Code style issues that arise, because of absence of a tool like go-fmt also warrant a comment. That's sad.
There are meaningful comments, but usually people have to fill their review quota.
Lowest hanging fruit should be just an in-place edit that would be automatically retested and that a reviewee can easily take as a patch and check himself. Instead of the back and forth bullshit.
It's a bit funny that placing a red herring comment that anyone can safely comment on makes the workflow faster. It's like this story about an artist who would place something ridiculous so when the time comes the CEO would just say: "It's good, just remove the thing".
Part of this process, especially for new team members or junior devs, is to signal that, yes, we take typos (and formatting, and proper grammar, and the style guide, etc) seriously. I could fix this myself, but I shouldn't need to. We all make mistakes, but too many "small" mistakes is an indication of sloppiness. Is this actually a mistake? Or were you just being lazy?
Agreed. In my team I am known for being extremely meticulous about this, and some people don’t like it. If I see one or two typos or spacing issues, I understand that’s an honest mistake. But if I see typos, spacing issues, bad indentation, bad naming, etc. all over your diff, I can’t help but think you’re sloppy. If you don’t care about the little things like properly formatted code, I have a hard time believing you care about the big things like error checking and proper test coverage.
On the other hand, pointless bikeshedding quickly gets mutually tiresome in a setting where every line of code is reviewed in small increments. I also like to address these tiny inconsequential hangups politely when I disagree that they're important. Let's say some guy suggests changing "name" to "someNeedlesslyDescriptiveName" and I'll point out that it's already clear what it is because it's the only variable in the needlesslyDescriptive function.
In business settings, I've seen plenty of pull requests "go stale". Usually, they come about from a) the person not updating their code based on reviews, b) the reviewers not reviewing in a timely manner, or c) the change is no longer necessary / a priority.
Usually, it is some combination of a and b. All cases are an indication of a deeper problem. None can be fixed by calling your "pull request" a "managed push" nor by giving people unrestricted access to pushing code. It's typically either a problem with communication or priorities/expectations.
> 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.
Understood. It's just that the PR model only encourages that code review to happen at the very end of the process, when the submitter may have been polishing their work, testing it, and refining it for several days. It would be more efficient for it to occur periodically throughout development, rather than at the very end.
I don't necessarily see code reviews as the problem here. I think it's a very important aspect of development that unfortunately seems first in line to get cut back when other parts of the organization fail, when for the sake of quality I believe that the organization should be designed to always accommodate it.
For example, you mention waiting until the last minute and throwing away work. If this is such a big deal, maybe the units of work are too big or too loosely defined. Loosely defined as in "eh, we never needed this in the first place" or big as in "sorry about that but your 2000 LOC commit just isn't the right approach". Maybe github style reviews/pull requests are also not the best way to go about it. IMO the github style is pretty weird and shouldn't be conflated with reviewing in general.
At my current workplace, we use gerrit to review every commit. The only way that they'll ever get to master or a shared development branch is if they get a +2 vote. Maybe this is closer to a "managed push"? It's not rare that someone finds an issue, and when that happens it's very rare that it means scrapping the entire patch, and when that happens, it's usually a very small patch for a problem/feature that ended up being fixed elsewhere, so I definitely don't think it's a waste of time. Instead I am grateful that many of the patches didn't enter the codebase in their initial state.
Tech lead is dictator. You should have a tech lead who is at least 50% hands-on coding and is enforcing the code review system and participating in as many as possible.
What do you mean by throw away? The submitter can always make the requested changes. And if the pull requests are not even relevant then it's entirely a different issue.
Meaning the submitter just spent one week writing code that will have to be written over again. If they had requested feedback informally before the PR, they would have written the code correctly the first time.
Having a PR workflow in place doesn't (or at least shouldn't) stop that person from seeking out that informal feedback earlier. To me it seems like what you're really looking for is pair programming, not pre-completion reviews.
Or you can do pair and/or mob programming, where the review happens as the code is created. This eliminates the feedback loop and the creation of throwaway code.
Even when I pair program it is nice to have someone else review the code before merging. Or at a minimum do a 'self' code review after the work is complete, once you have pulled your head out of the weeds things might look different.
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? With code reviews twice or three times a week for large features under development?
Which still doesn't really make sense?! Plenty of open source development happens outside of github, and plenty of proprietary software development does use github ... so if that is what you mean, you could essentially say that about any software that happens to be used by some developers for the development of open source software!?
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.
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.
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.
I just left a project after I was unable to make peace with being the cleanup guy for an endless, never-improving stream of mediocre code. I am convinced that it's faster to write solid code in the first place.
Once there are two or more interacting layers of code, it gets really hard for the refactoring to catch up. If you fix a bug in a basic layer, the leaves of the codebase break. If you fix a bug in the leaves, you never get to refactor the core. If you want to stop the world and refactor everything at once, you get in the way of your quicker counterpart.
Or think of a multithreaded codebase without any synchronization. It definitely works well enough for demoing an "almost finished" product, but cleaning it up requires a lot of time and can introduce temporary regressions (deadlocks) that are worse than the bugs that the cleanup is supposed to solve (very spurious data corruption). It's a bit like the bullshit asymmetry:
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.
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.
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.
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.
I've done this very frequently on pet projects - except I'm both people. There are projects I have where I'd grab a drink, and bang something out for a few hours in the evening that works - and then, in the cold, sober light of day make sure the underlying ideas are still sound and refactor it to make it more readable.
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.
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.
"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.
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.
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.
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.
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.
I absolutely follow these principles, and I often joke that I do everything I can to idiot-proof my code because the next idiot who comes around is usually me.
But unless you get support for this from middle and upper management, you're fighting a losing battle. You can't fix the world from behind the scenes. I know, I've been trying for many years.
My immediate managers have always been supportive of this attitude, but since everyone above them is concerned only with "How fast can we ship this?", and has the attitude, "We care about code quality, unless that means we have to dedicate resources to it." and "We will gladly spent 10 units of next month's or next year's resources to save 1 unit of resources for this week's release."
I understand the pressures of business needs, and sometimes you really do need to ship ASAP and sacrifice features or the insurance of quality of a well-defined piece of your project for revenue's sake. But at some point, constant compromises point to flawed management.
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.
The problem here is that you're making the organizational culture _worse_ while you make the code better. And it's organizational dysfunction that led to your situation in the first place.
It's a dysfunctional organization that doesn't let you write quality code without lying (assuming you are correct that this is ultimately counter-productive for the organization's goals), and most every dysfunctional organization I've seen is characterized by lack of transparency and truth internally -- nobody knows what's really going on, so there's nothing to do but political games. I think that lack of internal honesty is a cause, not just a symptom. So your workaround to let you do quality work despite being in a dysfunctional organization, misleading your peers and/or managers/administrators, makes the organization's dysfunction even worse, making it even harder to do quality work. In another kind of vicious cycle.
After a bunch of years of programming professionally, I've come to the conclusion that my job includes not just trying to make the code better, but trying to make the organization better too. The same way you've got to 'fight' for quality code, you've got to 'fight' for healthy (honest and respectful) organizational culture.
There are some (many) places that are so dysfunctional that they seem hopeless, and maybe you can't easily leave and find other employment. You've got to do what you've got to do to stay sane (and keep your mind from dying) and I don't fault people for their coping strategies in such an organization, but I think misleading/lying (which is really just a kind of 'political' game of it's own) to give you space for code quality is likely to lead into a vicious cycle of descending badness all around, not ultimately leading to increased job satisfaction.
Your definition of fighting for a better organisation, boils down to replace people who are apt at nothing but political games with people who are apt with engineering knowledge.
You cant do that, unless you have a little island of sanity at the top, giving you a lifeline and air-support. Sorry, i for once m not good at office version of the game of thrones.
So what's the alternative to lying for what you hope is the greater good?
This is the advice that I give my colleagues who, after exhausting all other methods, try to squash technical debt before a 1 hour task becomes a 5 hour task. Leaving the job doesn't solve the problem (though it may save your sanity). In fact it might make it worse, because the leaving person is likely taking tacit knowledge with them.
I'm not saying that lying is preferred, but what else can one do?
You need to flip the script on the problem. It's no longer a technical problem, it's a management problem.
Management problems are solved with spreadsheets that show concrete numbers going up or down.
At the beginning of each sprint ask the manager what % of time developers should spend fixing quality issues on each story after the story is complete. 0%? 30%? 50%? Track it. Graph it.
At the end of the sprint ask developers "how do you feel about the quality of the code base this sprint? [ 0 dangerously unstable --- 100 - clean and perfect ]. Track it and graph it.
Track what % of stories in the sprint are "code quality" stories (e.g. upgrade node). Create a graph showing four consecutive sprints with 0% time allocated to code quality stories.
After about 4 sprints of this, provided you were reasonably open and transparent about what you were doing, you'll probably have a slightly freaked out product manager who is newly cognizant of the need to properly allocate time to "quality".
If it turns out he's an idiot who ignored your little game, well, you've amassed documentation necessary to make his bosses start considering his termination and replacement.
Don't fuck around with this stuff though - you can invite all sorts of problems if you're not careful with this approach. Assume everybody is honest and has good intent until proven otherwise.
I have not completely figured out what to do, but I'll say that if you leave because the organization is not interested in producing quality code and you don't want to work for such an organization, and they were unwilling to give you time (ie money) to produce quality and maintainable code -- the problems they have maintaining the code after you leave, having made efforts to educate/convince them of this fact and failing, _are not your fault_ and _not your problem_.
The tacit knowledge you take with you, when they were not willing to give you enough time to share/document this knowledge, or produce code that was more transparent, despite your efforts to tell them the consequences -- are _not_ your problem. Don't get Stockholm syndrome.
I realized at one job that I kept busting my ass to cover up for management failures (that I wouldn't get credit for saving them from)... they would NEVER LEARN. I was enabling terrible management and a toxic environment. They didn't even _realize_ I was saving them from themselves (and if I'm wrong and they were right and I wasn't, all the more fine it was for me to leave).
I just left a job where I knew that management would never learn. That was my primary reason for leaving. All other problems could have been fixed IF they would listen to the employees and/or learn from their own mistakes.
Alas, it was not meant to be. I feel like I was an enabler because there were a lot of things that I held together despite not receiving any support from management.
You're absolutely right, and my immediate bosses have dedicated themselves to laying down the law that good work requires more time. We live in a culture where there is a lot of technical debt inherited from a culture that used to be much worse than it is now, and I think we've made some progress on the front of not increasing the technical debt, by insisting on the resources to do things right. Now, reducing the technical debt is another matter.
I don't know why this comment is in gray. I have been repeatedly pressured to "make it run on GPUs" and needed to spin some fiction to buy time.
In the end, if your superior tries to micromanage but doesn't understand the details, then a lie woven from bits of truth, if it helps achieve a goal, is morally indistinguishable from the whole raw truth.
I've seen a lot of teams in a lot of organizations, both bad and good.
Good teams cheat in bad organizations. That's why they're good teams. Whatever your metric, code quality, quality of life, being kind and supportive -- in organizations that pervasively do it bad, good teams cheat in order to do it well.
I think the trick is that only a small group of people know that they cheat, otherwise some mid-level manager would come down on them, hard.
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.
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.
The downside to this approach is people. You risk other (well meaning or otherwise) developers trying to help fix your misunderstanding or telling your supervisor that you need help. Others may need to be in on it and sometimes that sort of environment breeds cut-throat behavior. If the business has the power to dictate unreasonable requirements people that break ranks to tell them what they want to hear can gain a political advantage.
People have different situations in life and the range of options that you have as an employee can vary pretty dramatically. However, here's how I tend to cope with these situations (in order of preference):
1. If I don't get the time to do what I think is necessary, then I lobby to make sure that it's my decision about how much time it takes. You're not going to get handed this on a silver platter, but the main argument is that as a developer you are making a good salary. The person paying that salary should get the best value from that money. If you have to do your job in handcuffs, you're not going to be able to give the best value.
2. If I'm not in a political situation to do #1 (and you should probably try to make sure you are before you actually stick your neck out), then I will note the constraints I have to work under. Making a project succeed when everything goes exactly as you want it to is relatively easy (well, TBH, I think it's never actually easy, but you get my point). What makes a great developer is making the project succeed even when you don't have everything your own way. So find a way to succeed with the constraints that you have. If you fail, make sure to make it obvious which constraints are causing the most problems. Usually after you fail you can get some extra leeway on those issues. Work on the issues one at a time, most important first. Eventually you can usually promote yourself to option #1.
3. If I can't do #1 and there is some reason why #2 fails (and I can't fix it), then I will go elsewhere. No point in sticking around in a place where you can't succeed. Wish everybody great luck. Express remorse that you couldn't get the kind of success that everybody wanted. Thank people for the opportunities that you had.
4. If I can't go because I have no other job, or I need to stay because my visa says so, or my spouse will go crazy from stress if I switch jobs, or a million other possible reasons... I'll keep working and keep studying exactly what's causing the problems. It's easy to conclude, "Joe is breaking everything. I hate Joe" (I only picked the name Joe because to the best of my recollection, I've never worked with someone named Joe). But you're stuck and you might as well learn about the situation in more detail. Wait and watch. I hate waiting. Man, do I hate waiting. But eventually it will pay off. Opportunities are out there. Your job is to recognise them.
That's it. Don't lie. You'll only get found out and then make your job a hundred times harder. Don't get dragged into petty politics. The job is hard enough without drama. Play it straight and give everyone the best chance they have to understand what you are doing and cooperate with you. Don't undermine people. Just do your best. It's not always easy sailing, but learn how to navigate rough waters and you'll be fine.
It's not even lying: the cycle is red-green-refactor, not red-green-done. Knowing when to extract functionality (and when to inline functionality) is part of our job, not a management concern.
I think we tend to forget this because we so often muddy management and technical work, but management's job is to tell you what to build. You are the professional and it is your job to know how best to build it.
You can try, but then your meticulously documented ticket about why it's a very bad idea to put SQL query fragments into "hidden" HTML form elements never gets prioritized into the sprint.
Meanwhile, the same outsourced developers are making even more things you haven't found yet for whatever managers have the most political clout this week.
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".
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."
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?
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.
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.
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.
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.
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 to help more developers standardise their code.
