Is all software bad software?
February 6, 2020 5:04 PM Subscribe
Developers of MetaFilter: does clean production code actually exist?
I've been programming since I was a kid, and I've been a web developer for 20 years. For much of that time, I was doing pretty low-level stuff – building shitty WordPress sites, and things of that nature. I was also lucky enough to be working mostly with my own code, and mostly on new development work (as opposed to ongoing maintenance of existing codebases).
Several years ago, I decided that it was time to level up my skills. So I learned a couple of MVC frameworks, got comfortable with some more advanced front-end stuff (such as Angular), etc. I fell in love with the power and elegance of these technologies.
So I made the career jump from "building shitty WordPress sites" to "application developer". I thought it'd be great – instead of shoveling WordPress spaghetti, I'd be able to architect clean, beautiful systems. I'd be able to apply the elegant patterns and principles that I'd been playing with in the real world.
And, uh – no.
After a few years, I have yet to see a single production codebase that isn't a nightmare. Those clean, clever architectures and paradigms that people illustrate in programming blogs? They don't seem to exist in the real world. At least, not as more than wishful thinking.
Real production code, from what I've seen, is duct tape on top of Band-Aids on top of chewing gum. It's a maze of half-broken, uncommented functionality, which no one fully understands, written with half a dozen competing styles and philosophies, which works just well enough to not explode.
In short, it's exactly what's described in the first three paragraphs of this article.
To be clear: I don't blame other developers for this state of affairs. I don't even blame management. It seems to be an inevitable consequence of the demands of business. I sure don't have a solution.
My question is: Is this just how commercial software development is? If I continue on this career path, am I condemning myself to week after week, month after month of plumbing these grim tunnels?
I was born with a gift for analytical thinking. I wanted to use that gift to build elegant, useful things that make people's lives better. Not to figure out how to shit-rig a support beam to keep a shantytown from falling apart for another week or two.
And if non-nightmarish production code does exist: what industries, management methodologies, development ecosystems, etc. should I be looking into to find it?
Thanks.
I've been programming since I was a kid, and I've been a web developer for 20 years. For much of that time, I was doing pretty low-level stuff – building shitty WordPress sites, and things of that nature. I was also lucky enough to be working mostly with my own code, and mostly on new development work (as opposed to ongoing maintenance of existing codebases).
Several years ago, I decided that it was time to level up my skills. So I learned a couple of MVC frameworks, got comfortable with some more advanced front-end stuff (such as Angular), etc. I fell in love with the power and elegance of these technologies.
So I made the career jump from "building shitty WordPress sites" to "application developer". I thought it'd be great – instead of shoveling WordPress spaghetti, I'd be able to architect clean, beautiful systems. I'd be able to apply the elegant patterns and principles that I'd been playing with in the real world.
And, uh – no.
After a few years, I have yet to see a single production codebase that isn't a nightmare. Those clean, clever architectures and paradigms that people illustrate in programming blogs? They don't seem to exist in the real world. At least, not as more than wishful thinking.
Real production code, from what I've seen, is duct tape on top of Band-Aids on top of chewing gum. It's a maze of half-broken, uncommented functionality, which no one fully understands, written with half a dozen competing styles and philosophies, which works just well enough to not explode.
In short, it's exactly what's described in the first three paragraphs of this article.
To be clear: I don't blame other developers for this state of affairs. I don't even blame management. It seems to be an inevitable consequence of the demands of business. I sure don't have a solution.
My question is: Is this just how commercial software development is? If I continue on this career path, am I condemning myself to week after week, month after month of plumbing these grim tunnels?
I was born with a gift for analytical thinking. I wanted to use that gift to build elegant, useful things that make people's lives better. Not to figure out how to shit-rig a support beam to keep a shantytown from falling apart for another week or two.
And if non-nightmarish production code does exist: what industries, management methodologies, development ecosystems, etc. should I be looking into to find it?
Thanks.
It seems to be an inevitable consequence of the demands of business.
Yes, it’s called capitalism, and it (usually, often) pokes a finger in the eye of us having nice things, imo.
I’m not a commercial developer but I’ve spent a lot of the last 20 years writing and reading code for scientific computing, and most of it fails to meet my standards, including most of my own, because the things that make a code base nice and usable and elegant and readable and extensible are not the things that are supported or particularly rewarded, so far as I can tell.
It’s probably a little different in the business world but I can’t imagine it feeling any more wholesome than the academic research world, which is nominally non-profit and for the public good.
posted by SaltySalticid at 5:33 PM on February 6, 2020 [3 favorites]
Yes, it’s called capitalism, and it (usually, often) pokes a finger in the eye of us having nice things, imo.
I’m not a commercial developer but I’ve spent a lot of the last 20 years writing and reading code for scientific computing, and most of it fails to meet my standards, including most of my own, because the things that make a code base nice and usable and elegant and readable and extensible are not the things that are supported or particularly rewarded, so far as I can tell.
It’s probably a little different in the business world but I can’t imagine it feeling any more wholesome than the academic research world, which is nominally non-profit and for the public good.
posted by SaltySalticid at 5:33 PM on February 6, 2020 [3 favorites]
In my experience, safety critical software isn't nearly as ugly as actively evolving commercial software. There's no ad-hoc duct tape because it's just as hard to get duct tape through the verification process as it is to get clean code.
The downside is that there can be a huge amount of legacy code. Once code is qualified and field-proven, there are very strong incentives not to replace it with newer and shinier code.
However, as a programmer, I spend 90% of my time writing and reviewing specifications, 3% writing code, and 7% testing code. Most programmers don't enjoy that sort of working environment.
posted by monotreme at 5:34 PM on February 6, 2020 [7 favorites]
The downside is that there can be a huge amount of legacy code. Once code is qualified and field-proven, there are very strong incentives not to replace it with newer and shinier code.
However, as a programmer, I spend 90% of my time writing and reviewing specifications, 3% writing code, and 7% testing code. Most programmers don't enjoy that sort of working environment.
posted by monotreme at 5:34 PM on February 6, 2020 [7 favorites]
It seems to be an inevitable consequence of the demands of business.
This stood out for me also.
I have a bunch of projects at work where I'd love to clean up the code, make it bulletproof, readable to others (or myself in six months...), faster, lighter etc... but the demands of the business are such that more shitty code that just satisfies a separate business need is more important than tidying up things that already (even if just-barely) work.
Certainly, there's an argument to be made that you could get more value in the long-run by writing beautiful, elegant code in the first place, but even making that business-case is using up time that could be spent doing something else that needed to be done yesterday.
I don't know that I can answer the question, because I've not coded in all contexts. I have a friend who once wrote things for train control stuff. I understand that that was very well controlled and audited etc, because trains-full-of-people type liability, plus the constraints of embedded systems.
Maybe look for an industry where the 'demands of business' line up well with 'efficient, clean, maintainable code'?
posted by pompomtom at 5:47 PM on February 6, 2020 [7 favorites]
This stood out for me also.
I have a bunch of projects at work where I'd love to clean up the code, make it bulletproof, readable to others (or myself in six months...), faster, lighter etc... but the demands of the business are such that more shitty code that just satisfies a separate business need is more important than tidying up things that already (even if just-barely) work.
Certainly, there's an argument to be made that you could get more value in the long-run by writing beautiful, elegant code in the first place, but even making that business-case is using up time that could be spent doing something else that needed to be done yesterday.
I don't know that I can answer the question, because I've not coded in all contexts. I have a friend who once wrote things for train control stuff. I understand that that was very well controlled and audited etc, because trains-full-of-people type liability, plus the constraints of embedded systems.
Maybe look for an industry where the 'demands of business' line up well with 'efficient, clean, maintainable code'?
posted by pompomtom at 5:47 PM on February 6, 2020 [7 favorites]
Is this just how commercial software development is? If I continue on this career path, am I condemning myself to week after week, month after month of plumbing these grim tunnels?
Two important concepts: "greenfield" and "start-up". The latter is the easiest place to find the former.
Otherwise, yes, expect to spend your career wading through other people’s muck. And really greenfields are just a chance to wade through your own muck in 6 months.
posted by Tell Me No Lies at 5:52 PM on February 6, 2020 [11 favorites]
Two important concepts: "greenfield" and "start-up". The latter is the easiest place to find the former.
Otherwise, yes, expect to spend your career wading through other people’s muck. And really greenfields are just a chance to wade through your own muck in 6 months.
posted by Tell Me No Lies at 5:52 PM on February 6, 2020 [11 favorites]
A friend has four lines of code in the ISS.
It took six months of meetings to develop the spec, then a further six months of testing.
Compare that with the financial house where I worked that the CEO wrote Perl code while unable-to-stand-straight drunk. This managed millions of dollars worth of client money
posted by scruss at 5:54 PM on February 6, 2020 [26 favorites]
It took six months of meetings to develop the spec, then a further six months of testing.
Compare that with the financial house where I worked that the CEO wrote Perl code while unable-to-stand-straight drunk. This managed millions of dollars worth of client money
posted by scruss at 5:54 PM on February 6, 2020 [26 favorites]
To the extent that good coding practice exists in a lot of projects, it's often only in the way that it can silo these duct-taped monstrosities from one another. So when something falls over in one part of the code, one, it's easy to identify what component/module/function/part has gone wrong, and, two, it doesn't cause catastrophic failure elsewhere. And that's often "good enough."
No one (edit: with the authority to determine the allocation of resources) wants to refactor the legacy system that "just works," because the guy who built it doesn't work for us any more, and so long as it keeps working, it isn't a problem.
posted by juv3nal at 6:01 PM on February 6, 2020 [2 favorites]
No one (edit: with the authority to determine the allocation of resources) wants to refactor the legacy system that "just works," because the guy who built it doesn't work for us any more, and so long as it keeps working, it isn't a problem.
posted by juv3nal at 6:01 PM on February 6, 2020 [2 favorites]
https://www.fastcompany.com/28121/they-write-right-stuff
posted by Poldo at 6:05 PM on February 6, 2020 [1 favorite]
posted by Poldo at 6:05 PM on February 6, 2020 [1 favorite]
It really depends on the company and culture behind the codebase. I have seen both, or different types in different parts of a company, depending on the teams.
posted by nickggully at 6:07 PM on February 6, 2020 [1 favorite]
posted by nickggully at 6:07 PM on February 6, 2020 [1 favorite]
Let us imagine you discovered a "clean" project. Congratulations, you've just solved last week's problems. Here are this week's requirements.
Any non-trivial coding project will eventually accumulate cruft for the simple reason that the system (database, code, UI) is attempting to model the real world, and the real world is not clean. Spend a few minutes watching this discussion of the problem of time zones to understand what I'm talking about. To a naive programmer, this should be a clean problem. Spoiler alert: it's not!
posted by SPrintF at 6:14 PM on February 6, 2020 [18 favorites]
Any non-trivial coding project will eventually accumulate cruft for the simple reason that the system (database, code, UI) is attempting to model the real world, and the real world is not clean. Spend a few minutes watching this discussion of the problem of time zones to understand what I'm talking about. To a naive programmer, this should be a clean problem. Spoiler alert: it's not!
posted by SPrintF at 6:14 PM on February 6, 2020 [18 favorites]
A friend has four lines of code in the ISS.
It took six months of meetings to develop the spec, then a further six months of testing.
I assume that’s out of JPL. JPL is (last I checked) regarded as the best software organization that exists, hundreds of times better than your average commercial operation. The example above is not some extreme case for them, everything is done that way.
However, they still managed to plow the Mars Climate Orbiter right into the planet, not due to an error in their software but due to a failure to test extensively enough with some third-party systems.
Moral: even in the absolute best case things are going to go wrong. Expect to spend a lot more time dealing with that then the brochure promised.
posted by Tell Me No Lies at 6:28 PM on February 6, 2020 [5 favorites]
It took six months of meetings to develop the spec, then a further six months of testing.
I assume that’s out of JPL. JPL is (last I checked) regarded as the best software organization that exists, hundreds of times better than your average commercial operation. The example above is not some extreme case for them, everything is done that way.
However, they still managed to plow the Mars Climate Orbiter right into the planet, not due to an error in their software but due to a failure to test extensively enough with some third-party systems.
Moral: even in the absolute best case things are going to go wrong. Expect to spend a lot more time dealing with that then the brochure promised.
posted by Tell Me No Lies at 6:28 PM on February 6, 2020 [5 favorites]
Ultimately, any non-trivial project will run afoul of Conway's Law.
posted by tobascodagama at 6:34 PM on February 6, 2020 [6 favorites]
posted by tobascodagama at 6:34 PM on February 6, 2020 [6 favorites]
Exactly what pompomtom said. The best systems I've seen are the result of a team continually trying to balance a good developer's desire for perfection with the business need for actual results - too far in either direction and it falls apart. It's just as bad for someone to write bindings for 3 languages that don't yet need them as it is to put in some crappy bit-packing hack to get something done tomorrow. I don't think this is a particularly stable equilibrium; it requires the right team and the right company. But when it happens it's really something to be a part of.
To your second question: agreed with nickggully . I think that there are companies that cannot support this due to company culture, but even in companies that can it's not evenly distributed. I'd look for a product that's been in production for a few years where during the interview process the development team doesn't tell you that your new job will be writing version 2.0 of the system.
posted by true at 7:11 PM on February 6, 2020 [2 favorites]
To your second question: agreed with nickggully . I think that there are companies that cannot support this due to company culture, but even in companies that can it's not evenly distributed. I'd look for a product that's been in production for a few years where during the interview process the development team doesn't tell you that your new job will be writing version 2.0 of the system.
posted by true at 7:11 PM on February 6, 2020 [2 favorites]
I have seen beautiful production code. My guess is that it happens when you have a good model of your problem and the right abstractions with which to build its solution.
Of the beautiful production code I've seen, one was a library for describing the foreign function interface between two programming languages, written in a language developed originally for writing compilers.
Another was a bit of numerical computing where somebody showed that under certain conditions something could be expressed as a single line of matrix arithmetic. The resulting "_unchecked" function was beautiful.
What was not beautiful:
- the comment describing when you could use the unchecked function
- the wrapper that did the checking at runtime
- the underlying linear algebra libraries (I assume)
Conversely, then, we would expect that if one doesn't understand the problem or doesn't have the right building blocks, then one will produce bad code. And indeed that seems to be true of the spaghetti code I've seen: it's a mess of hacks to handle cases that weren't anticipated originally, or to patch up the results of re-using something that doesn't quite fit the role it must perform here.
posted by meaty shoe puppet at 7:14 PM on February 6, 2020
Of the beautiful production code I've seen, one was a library for describing the foreign function interface between two programming languages, written in a language developed originally for writing compilers.
Another was a bit of numerical computing where somebody showed that under certain conditions something could be expressed as a single line of matrix arithmetic. The resulting "_unchecked" function was beautiful.
What was not beautiful:
- the comment describing when you could use the unchecked function
- the wrapper that did the checking at runtime
- the underlying linear algebra libraries (I assume)
Conversely, then, we would expect that if one doesn't understand the problem or doesn't have the right building blocks, then one will produce bad code. And indeed that seems to be true of the spaghetti code I've seen: it's a mess of hacks to handle cases that weren't anticipated originally, or to patch up the results of re-using something that doesn't quite fit the role it must perform here.
posted by meaty shoe puppet at 7:14 PM on February 6, 2020
I assume that’s out of JPL. JPL is (last I checked) regarded as the best software organization that exists, hundreds of times better than your average commercial operation. The example above is not some extreme case for them, everything is done that way.
Small point of contention, JPL (and their ilk) are not regarded as the best software orgs that exist, they are the regarded as some of the most rigorous. Those two things are not the same, and as many people upthread pointed out ultimately it's the balance between rigor and practicality that matters, not the in-a-vacuum (pun intended) correctness of code.
posted by so fucking future at 9:06 PM on February 6, 2020 [11 favorites]
Small point of contention, JPL (and their ilk) are not regarded as the best software orgs that exist, they are the regarded as some of the most rigorous. Those two things are not the same, and as many people upthread pointed out ultimately it's the balance between rigor and practicality that matters, not the in-a-vacuum (pun intended) correctness of code.
posted by so fucking future at 9:06 PM on February 6, 2020 [11 favorites]
I've seen some very nice production code. It requires that the people with clout on the team care more about clean, readable, well-tested code than about hitting deadlines. That's a rare breed in software engineering because in general if you miss a lot of deadlines they don't let you be in charge. And oh god, it is HARD to go from a team like that to a normal software team. I got terrible job evaluations for like a year because they thought I was so, so slow. They didn't value the time I was spending on code quality, they just wanted me shipping.
posted by potrzebie at 10:35 PM on February 6, 2020 [4 favorites]
posted by potrzebie at 10:35 PM on February 6, 2020 [4 favorites]
I’ve spent my the whole of my current career coding at the coal face. There have been times when I’ve deliberately chosen to create technical debt; other times, I’ve been saddled with cleaning it up without breaking jobs.
Beautiful code, with documentation and run thru linter, exists in my company. But it’s on stuff that is never used facility wide nor mission critical.
posted by lemon_icing at 1:08 AM on February 7, 2020
Beautiful code, with documentation and run thru linter, exists in my company. But it’s on stuff that is never used facility wide nor mission critical.
posted by lemon_icing at 1:08 AM on February 7, 2020
Let us ignore JPL code as it can actually be considered to be bad code depending on your definition of good or bad. Early cars were designed for aristocratic families of Europe and were lovingly produced by hand, see the 1938 Bugatti. The Model T was reliable, affordable and did the job well enough. There are more Model T Wordpress sites out there then multi-billion dollar satellites. Which is better?
I think the answer really is that it is not comparable for a myriad of reasons, good and bad both of connotations to them. Shitty Wordpress sites are incredibly common, run large portions of the Internet and by that metric they are good. JPL software that fails is so notorious case studies are written about it. If code were produced to JPL standards I doubt we'd be here talking on a Coldfusion site.
With that said software is like anything else in life, shortcuts are made and knowing when to make shortcuts comes with experience and shouldn't be labeled good or bad. Does a feature need to be added on at the last minute? Is it a hack? "Good" software would isolate that hack to reduce the dreaded term technical debt.
Whenever I think of "good" versus "bad" software I think of the horror story of Microsoft Office that had all the hallmarks of a bad project. Yet it can arguably be said to be one of the most successful and widely used software suites today. Red Dead Redemption was so notoriously horribly written it barely made it out the door and is considered a classic game.
And to come back to why I say to ignore JPL code. Please tell me I'm wrong but there's not discussions about unforeseen specifications on the Voyager satellites. No one new is coming and demanding Okta be used for authentication. I'm sure there's updates to software code but they're necessary and not necessarily driven by market demands but real world problems.
In summary I would not consider "good" or "bad" based on error rate or market success. Can you add an unforeseen feature in the future easily and isolated? Can you do this without ruining your work life balance? Do developers enjoy working on the code base? That would be good software in my opinion.
posted by geoff. at 4:03 AM on February 7, 2020 [2 favorites]
I think the answer really is that it is not comparable for a myriad of reasons, good and bad both of connotations to them. Shitty Wordpress sites are incredibly common, run large portions of the Internet and by that metric they are good. JPL software that fails is so notorious case studies are written about it. If code were produced to JPL standards I doubt we'd be here talking on a Coldfusion site.
With that said software is like anything else in life, shortcuts are made and knowing when to make shortcuts comes with experience and shouldn't be labeled good or bad. Does a feature need to be added on at the last minute? Is it a hack? "Good" software would isolate that hack to reduce the dreaded term technical debt.
Whenever I think of "good" versus "bad" software I think of the horror story of Microsoft Office that had all the hallmarks of a bad project. Yet it can arguably be said to be one of the most successful and widely used software suites today. Red Dead Redemption was so notoriously horribly written it barely made it out the door and is considered a classic game.
And to come back to why I say to ignore JPL code. Please tell me I'm wrong but there's not discussions about unforeseen specifications on the Voyager satellites. No one new is coming and demanding Okta be used for authentication. I'm sure there's updates to software code but they're necessary and not necessarily driven by market demands but real world problems.
In summary I would not consider "good" or "bad" based on error rate or market success. Can you add an unforeseen feature in the future easily and isolated? Can you do this without ruining your work life balance? Do developers enjoy working on the code base? That would be good software in my opinion.
posted by geoff. at 4:03 AM on February 7, 2020 [2 favorites]
As someone who came from yet another one of those shitty code environments, one thing to look for is that the people who write the code are also the people who fix the bugs. Ideally the exact same people. My previous job had a support team that wrote code to fix bugs, and that is what I did. I feel like that encouraged the mindset of 'get it shipped, it works 75% of the time,' because they knew support would fix the 25% edge cases -- it was their job. Personally I enjoyed the fixing, but the code was, generally speaking, a complete nightmare, and there was no accountability to make the developers write better code. You made the most minimal changes possible, no refactoring, because chances were good you'd break something else.
While I was there they started a massive project to move our application from a client-server base to a web base, and instead of starting from the ground up with beautifully architectured code, they ported over the nightmare so they didn't have to build a new database. Several developers quit. Others joined and then it was just status quo.
As far as I know, they are still working on the web-based nightmare. A lot of that was due to management decisions.
posted by possibilityleft at 6:20 AM on February 7, 2020 [4 favorites]
While I was there they started a massive project to move our application from a client-server base to a web base, and instead of starting from the ground up with beautifully architectured code, they ported over the nightmare so they didn't have to build a new database. Several developers quit. Others joined and then it was just status quo.
As far as I know, they are still working on the web-based nightmare. A lot of that was due to management decisions.
posted by possibilityleft at 6:20 AM on February 7, 2020 [4 favorites]
I've seen / been able to write good software similar to monotreme's 'safety critical' where they give programmers time to do it righter. Mission Critical Infrastructure. They give you time when your code could cause everything to melt down. It also helps when the handful of people doing this stuff are all enough of the whole system (analyst, architect, engineer, programmer) spread. I doubt you find this in the commercial world where there's a lot of hierarchy and cat herding.
posted by zengargoyle at 8:43 AM on February 7, 2020 [1 favorite]
posted by zengargoyle at 8:43 AM on February 7, 2020 [1 favorite]
I spent my first eight years of employment as a software engineer at a small software consultancy in a safety-critical domain. I've spent the last eight years trying to apply the principles I learned there in my current role as a senior software developer at a small software firm in a non-safety-critical domain. The result has been somewhat frustrating. Everyone has the best intentions, nobody wants to write spaghetti code, but commercial pressures are what they are.
If code quality is important to you - and I'd put beauty under the heading of "code quality", along with maintainability - but you don't fancy writing e.g. engine management software, then based on my own experience I'd recommend finding non-safety-critical work at a company that also does a lot of safety-critical embedded stuff. In that scenario, there's at least a chance that the standards required to keep from killing people will seep out into the wider company.
posted by ManyLeggedCreature at 9:01 AM on February 7, 2020 [5 favorites]
If code quality is important to you - and I'd put beauty under the heading of "code quality", along with maintainability - but you don't fancy writing e.g. engine management software, then based on my own experience I'd recommend finding non-safety-critical work at a company that also does a lot of safety-critical embedded stuff. In that scenario, there's at least a chance that the standards required to keep from killing people will seep out into the wider company.
posted by ManyLeggedCreature at 9:01 AM on February 7, 2020 [5 favorites]
There's a lot of individual variation, but I think there are tendencies. Code that is the actual product of the organization tends to be very good. The Qt cross-platform GUI library handles the complex task of making wildly different windowing systems look more or less the same from a programming standpoint, and it is the primary product of the Qt organization. It is excellent. Standardized interfaces, excellent documentation, the works. Contrast that with software that will never see the light of day, has a short lifetime, and is in general a side effect of whatever business purpose the organization is trying to accomplish.
posted by wnissen at 9:03 AM on February 7, 2020
posted by wnissen at 9:03 AM on February 7, 2020
I think some of it is also a selection effect from what people work on regularly. You don't see good production code because:
- It is isolated from ever-changing business requirements, which continually go beyond the original intents of the original production code ideas, which is why it becomes a mess.
- No one works on something that doesn't break and doesn't need enhancement.
There is always some long-forgotten script or code somewhere that has been running for years, maybe even decades, that is crucial to the company and hasn't failed in any way as to draw attention to it. When something in it does need to be changed (and in a way corresponding to its original design) it is often done so quickly and effortlessly to not even be noteworthy.
posted by meowzilla at 11:28 AM on February 7, 2020 [1 favorite]
- It is isolated from ever-changing business requirements, which continually go beyond the original intents of the original production code ideas, which is why it becomes a mess.
- No one works on something that doesn't break and doesn't need enhancement.
There is always some long-forgotten script or code somewhere that has been running for years, maybe even decades, that is crucial to the company and hasn't failed in any way as to draw attention to it. When something in it does need to be changed (and in a way corresponding to its original design) it is often done so quickly and effortlessly to not even be noteworthy.
posted by meowzilla at 11:28 AM on February 7, 2020 [1 favorite]
Can't say I've seen that much good code in production but here's my attempt at answering your last question as I've been thinking about this a lot recently:
Design
Why: For code to be good, it probably needs at least a decent reason to be created and a good plan for its implementation.
Tools: ??? (someone please educate me on this)
Specification
Why: Without a well written specification I'm starting to consider our programs bug free - what we often call a bug is simply unspecified behaviour, but the same goes for our features :)
Tools: More formal spec languages like TLA+ or Alloy, to less formal specs like statecharts ala https://sketch.systems/
Coding
Why: We need to implement our programs against some specification, we can do that well in a way that is readable, correct and performant or we can do it poorly.
Tools: "Clean Code" principles, TDD, Automatic code formatting, Static typing, Getting your code reviewed by someone good at coding
Testing / Verifying
Why: We need to test or verify our implementation against the specification to deem it correct.
Tools: Static typing, Combination of BDD manual / oracle / example based tests and property based testing at application level, e2e testing at public API level
posted by xobapd at 3:51 PM on February 7, 2020
Design
Why: For code to be good, it probably needs at least a decent reason to be created and a good plan for its implementation.
Tools: ??? (someone please educate me on this)
Specification
Why: Without a well written specification I'm starting to consider our programs bug free - what we often call a bug is simply unspecified behaviour, but the same goes for our features :)
Tools: More formal spec languages like TLA+ or Alloy, to less formal specs like statecharts ala https://sketch.systems/
Coding
Why: We need to implement our programs against some specification, we can do that well in a way that is readable, correct and performant or we can do it poorly.
Tools: "Clean Code" principles, TDD, Automatic code formatting, Static typing, Getting your code reviewed by someone good at coding
Testing / Verifying
Why: We need to test or verify our implementation against the specification to deem it correct.
Tools: Static typing, Combination of BDD manual / oracle / example based tests and property based testing at application level, e2e testing at public API level
posted by xobapd at 3:51 PM on February 7, 2020
Yes and no. It's not so much about the code as about the model. If you have a clean, simple, elegant model you'll get clean, simple and elegant code.
Unfortunately the real world is none of those things, so the closer your model gets to modelling reality the messier it, and the code that falls out of it, becomes. Add to that the fact that the model is a moving target, and all hope is lost.
But I don't think that's a bad thing. All those little kludges and hacks show that your model is moving closer to describing reality, and that's got to be a good thing. Messiness in code is like scar tissue in humans - a badge of pride, proof you're a survivor. How much messiness would you have to add to implement these real-world corner cases?
posted by Leon at 4:01 PM on February 7, 2020 [2 favorites]
Unfortunately the real world is none of those things, so the closer your model gets to modelling reality the messier it, and the code that falls out of it, becomes. Add to that the fact that the model is a moving target, and all hope is lost.
But I don't think that's a bad thing. All those little kludges and hacks show that your model is moving closer to describing reality, and that's got to be a good thing. Messiness in code is like scar tissue in humans - a badge of pride, proof you're a survivor. How much messiness would you have to add to implement these real-world corner cases?
posted by Leon at 4:01 PM on February 7, 2020 [2 favorites]
In my experience, cleaner code exists, but never perfect. I’ve never been involved in avionics or medicine or anything where it has to be super perfect though.
The only strategy that’s ever worked for me is to accept imperfection, pay down technical debt whenever possible, and keep stakeholders well aware of what needs to be revisited.
The best code I’ve ever seen was in situations where the developers had a lot of clout and could seriously push on deadlines, budgets, and limit the feature set. Usually this was in a v2 situation, where v1 had failed due to the normal bullshit and the client had been extremely burned.
And finally, I’ve never seen good css in a project more than 48 hours old. I’m not convinced it exists.
posted by condour75 at 4:11 PM on February 7, 2020 [2 favorites]
The only strategy that’s ever worked for me is to accept imperfection, pay down technical debt whenever possible, and keep stakeholders well aware of what needs to be revisited.
The best code I’ve ever seen was in situations where the developers had a lot of clout and could seriously push on deadlines, budgets, and limit the feature set. Usually this was in a v2 situation, where v1 had failed due to the normal bullshit and the client had been extremely burned.
And finally, I’ve never seen good css in a project more than 48 hours old. I’m not convinced it exists.
posted by condour75 at 4:11 PM on February 7, 2020 [2 favorites]
(Although thinking about it, I might be talking about inherent complexity (this is a complex problem) while you're more concerned with incidental complexity (this is a complex codebase)).
posted by Leon at 4:13 PM on February 7, 2020
posted by Leon at 4:13 PM on February 7, 2020
One more thing, if you go to a place that does mission critical things you may find it boring and limited in your toolset. So there’s always a tradeoff. I personally try to position myself at the beginning of projects, before it goes bad. It is satisfying coming back to a project you architected and seeing it not a mess and more or less how you set it up. So the notion commercial products always go bad is not always correct. See my previous recent questions on the “standardization” of microservices. I had unwittingly been doing this for years, but without the formality now present. While it might take extra work to create a new project and you might do it on your time (people will rightfully point out that’s employer abusing your time but putting in 60 hours once in awhile for clean maintainable code is worth it for my personal satisfaction).
Oh and that clean code you see online are just meant to building blocks. I’ve seen people way over engineer something to avoid breaking a pure software pattern. I’d rather keep it simple and introduce the one thing you’re not supposed to do.
posted by geoff. at 3:33 PM on February 8, 2020
Oh and that clean code you see online are just meant to building blocks. I’ve seen people way over engineer something to avoid breaking a pure software pattern. I’d rather keep it simple and introduce the one thing you’re not supposed to do.
posted by geoff. at 3:33 PM on February 8, 2020
Someone on my team just shared this:
Which isn't to say that it's often used, just that there are people who are thinking about stuff like this. FWIW, one of our standard interview questions is about how candidates manage technical debt; in particular what strategies they use to ensure that technical debt is paid down while juggling client deadlines.
posted by taltalim at 9:41 AM on February 9, 2020
Which isn't to say that it's often used, just that there are people who are thinking about stuff like this. FWIW, one of our standard interview questions is about how candidates manage technical debt; in particular what strategies they use to ensure that technical debt is paid down while juggling client deadlines.
posted by taltalim at 9:41 AM on February 9, 2020
And if non-nightmarish production code does exist: what industries, management methodologies, development ecosystems, etc. should I be looking into to find it?
Good code does exist. A good question to ask a prospective employer is "how do you manage technical debt?".
Every workplace will have times when the pressure of deadlines means that technical debt is accrued. Workplaces that produce good code will have the rigor and discipline to clean up technical debt, rather than continuously accruing it.
Real production code, from what I've seen, is duct tape on top of Band-Aids on top of chewing gum. It's a maze of half-broken, uncommented functionality, which no one fully understands, written with half a dozen competing styles and philosophies, which works just well enough to not explode.
Any prospective employer who gives you a blank look in response to the technical debt question is very likely to have code like you describe.
If you want clean code, you want to work somewhere that has a process to clear technical debt, and sticks to it. The interviewer should be able to tell you what that process is.
posted by HiroProtagonist at 8:02 PM on February 9, 2020 [1 favorite]
Good code does exist. A good question to ask a prospective employer is "how do you manage technical debt?".
Every workplace will have times when the pressure of deadlines means that technical debt is accrued. Workplaces that produce good code will have the rigor and discipline to clean up technical debt, rather than continuously accruing it.
Real production code, from what I've seen, is duct tape on top of Band-Aids on top of chewing gum. It's a maze of half-broken, uncommented functionality, which no one fully understands, written with half a dozen competing styles and philosophies, which works just well enough to not explode.
Any prospective employer who gives you a blank look in response to the technical debt question is very likely to have code like you describe.
If you want clean code, you want to work somewhere that has a process to clear technical debt, and sticks to it. The interviewer should be able to tell you what that process is.
posted by HiroProtagonist at 8:02 PM on February 9, 2020 [1 favorite]
« Older Please help my very private husband navigate a... | Why isn't Netflix working after only playing one... Newer »
This thread is closed to new comments.
Yes, there absolutely is good software, written by people that care, who take the time to architect and organize things. I've worked at places where everything is a mess, and I've worked at places where most things were really well thought out and built by smart, intentional and deliberate people. It is not an attribute of a specific industry or niche, it's the attribute of a good team and good organization. Organizations where programming is not considered overhead perhaps skew a little better here (vs places where "oh just ship it already, lazy programmers" attitudes prevail).
That said, computers are the. fucking. worst. They will find a new way and exciting ways to break always and forever. Programming involves dealing with those things -- analytical thinking is exactly the sort of skill that helps you be good at dealing with those things. It will never be a job that is all puppies and sunshine and rainbows, everything stands on too many layers of abstraction for any one mind to prove them sound top to the bottom. It doesn't have to be a terrible mess either though.
posted by so fucking future at 5:14 PM on February 6, 2020 [13 favorites]