Maintaining code quality when nobody cares
mkdev.me
mkdev.me
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.
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.
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.
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.
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 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.
Maybe what I learned from it alone would be worth the effort. Tough to say.
This is on top of the "never work for free" rule. All that does is bring down the value and respect of our entire industry.
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.
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.
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.
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.
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.
"If it's just a stepping stone, then be fascinated by the shape of the stone"
-Ze Frank
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.
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'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.
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.
http://www.reddit.com/r/Welding/comments/1z9oc1/serious_how_...
Almost always the answer will be no. So you're forced in a way to ship bad code.
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."
Fix the vulnerability if you can. Help junior developers understand common issues if you can. Then move on to the next job with better practices.
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.
whoever works with you will have to bear the burden that you left behind because you think its a low ROI for YOU
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've known of or read the situation where someone opens some old code, thinks "Who wrote this hot garbage?", and then realizes it was them.
Did it work? Can you read and understand it? Then it has value.
Finding the right line in the sand for your current job is an art. There is ALWAYS more you can do, and being smartly-selfish is inevitable.
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.
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.
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.
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.
Please advise.
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.
I thought the idea was to have less bugs to worry about...
Work for a company and project sending astronaut to Mars, then you can care and be surrounded by coworkers who care too.
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.
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.
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...
Major refactors certainly need to be accounted for in a sprint(s), but keep features a priority when needed in sprints.
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.
At some point you'll start recognizing structures in the code some of which will be small enough to surgically improve.
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.
Edit: formatting, because HN doesn't do markdown.
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.
https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fen...
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.
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.
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.
Rule 2: One bullshit hack must be removed per sprint.
Over time, you'll have better software.
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 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”.
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.
lint [cosmetic | medium | serious]
lint medium --against=branch
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.
For the second, see git-lint: https://github.com/sk-/git-lint
Regarding the changeset, I think you could roll that pretty easily with something like `git diff --name-only | xargs eslint`.
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.
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.
[1] http://luacheck.readthedocs.io/en/stable/warnings.html
[2] I'm not entirely happy with the formatting issues, but they can be easily disabled.
Edit: hit submit by mistake.
But the bigger point is that you reduce merge conflicts since you won't have all sorts of unrelated formatting changes mixed in with the real changes.
I don't know how these kinds of people live with themselves or are tolerated by others. I hate it.
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.
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.
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'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.
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).
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.
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.
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.
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.
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)
Needless to say, it's time for a move upward and outward.
Is it just me, or is less that four years not "really old"?
By the tone of the article, the author is clearly talking about the second kind.
Java code, C++ and python from 2014 could be untouched and still working fine.
Software does not age well when it isn't constructed properly.
"They're writing legacy code, man!"
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 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.
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.
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.)
"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.
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.
Given that we need a lot of housing and we don't have many home builders, there are a lot of tents floating around this industry.
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.
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.
// Copyright (C) 1991 - 1999 Rational Software Corporation
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.
In the JS world 4 years is very old bu in the C/C++ world 4 years are still quite fresh.
software isn't old until it breaks 10 yrs!
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.
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".
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.
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.
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.
What would you do different in "managed push"?
Erm ... GitHub is entirely proprietary!?
(paraphrased from some original quote I can't remember)
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.
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?
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:
https://twitter.com/ziobrando/status/289635060758507521
Ruby on Rails (from the OP) makes it easy to build many kinds of maintenance deathtraps.
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.
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.
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 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.
Maybe tell them that double-entry bookkeeping doubles their workload and they could go faster with single-entry bookkeeping.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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).
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.
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.
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.
I'm not saying this to brag, but to emphasize that this is what it takes to do quality work.
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.
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.
If you never get to version 3, you never get the opportunity to worry about code quality.
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."
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?