7 ms·

> Writing good software can be hard, but it is worth the time and effort. Is it? I want this to be true because I want to write good software. But I've worked

> Writing good software can be hard, but it is worth the time and effort. Is it? I want this to be true because I want to write good software. But I've worked with some very senior developers who would disregard all software engineering and user experience concerns and just spew large quantities of low-quality code that made the managers just as happy, especially since it got done quickly. And the end-users in many niche industries are used to being shipped garbage, so they're just as happy too.

lwansbrough 8y ago
Seems like you kind of answered your own question. :)
mathw 8y ago
Nah they're not happy, they're just trained to think it's how things have to be.
- CathyWest 8y ago
  You know that and I know that, but often it's easier said than done to convince them of it. I've had users get indignant because I dared criticise their favourite enterprise bloatware like I insulted their mothers. Even as they themselves were struggling with some misfeature keeping them from doing their actual work. But it does mean that it's easy to exceed their expectations, for example by making the browser back button take the user back to the previous view instead of crashing the entire user session. I tend to try to justify spending time solving technical debt by making development of new dazzling features faster and cheaper, but as long as the users (and more importantly their managers) are sufficiently dazzled if you only throw them a pittance once in a while, that becomes hard to sell.
bengale 8y ago
Pretty much my experience too. I don't think it's ever been worth the time or effort to spend time on writing quality software, the people that smash it out quickly are the ones rewarded. I'm starting to feel like the whole movement for 'software craftsmanship' is making a lot of developers miserable. It's maybe better for them to realise they are not artisans, they are bricklayers. To focus that creative energy on their own projects rather than getting burnt out fighting their managers over writing 'good software'.
- tonyedgecombe 8y ago
  I don't think you can turn it off like that. There are no Michaelangelos spending their day slapping emulsion on drywall.
  - maxerickson 8y ago
    Opportunity is not evenly distributed.
- collyw 8y ago
  >I'm starting to feel like the whole movement for 'software craftsmanship' is making a lot of developers miserable. Not as miserable as working on some 7 year old system hacked together without any craftsmanship. Plus if its a long term project the maintenance costs must spiral.
  - CathyWest 8y ago
    I think the point is that it's better to work on some 7 year old system hacked together without any craftsmanship with the belief that craftsmanship is nonsense and spaghetti code is a legitimate design pattern, than to work on it knowing there is a better way to design software.
danmaz74 8y ago
It depends so much on what you're doing. I've been in situations where junior or mid level devs spend a ridiculous amount of time on details that add almost no business value even in the long term. The best developers from the employer pov understand, depending on the project, which level is good enough.
manasirani 8y ago
https://canmypcrunit.org/horizon-zero-dawn-system-requirements/ https://canmypcrunit.org/horizon-zero-dawn-system-requiremen...
tonyedgecombe 8y ago
The end users aren't happy, they mostly hate the crap that is foisted on them.
- TheOtherHobbes 8y ago
  Very much this. People have incredibly low expectations of software, so of course the software industry feels no need to push for higher quality. Generally business considerations >> user happiness. Software is primarily shipped to make money. If a shitshow product - it's not hard to name a few - makes money, there is no business feedback loop which will raise quality. Senior devs tend to justify this on the basis of experience, and management justifies it on the basis of shareholder value. In reality it's just cheap, shoddy, dispiriting, and cynical. In a mature industry developers would be able to take pride in making end users happy [1], as opposed to making them frustrated and enraged. [1] Not the same goal as impressing developer peers.
- Viliam1234 8y ago
  They hate it, but they pay for it. Perhaps you could make something they love instead, but if the production then costs 10x more, and they are only willing to pay 2x more, it does not make sense economically.
xgbi 8y ago
Disclosure: small-ish company (~100 employees) in France You know, I kind of went through the same questioning: at my current company we have an employee that has his niche/historical role on one of the key infrastructure of our product. The guys works from his home and whatever hours, commits 300+ lines per commit (90% of which is unrelated to the commit name, just commenting things or uncommenting others). The code is a spagetti of if else if else, it has monstruous "client specific" code (like: if the current client is this guy, then do that, otherwise for all other clients do this). There's even a load of "if the program runs in test, answer what the test expects, otherwise in prod send something else". Every time I look at the commit tree (a balance of wanting to have fun and wanting to see what is going on), I'm in horror. The guy rewrote the java.lang.string, the java.lang.date, and some other base classe of the language to incorporate his own version of the Date handling. Fun fact, at one point his date parsing code "wasn't happy with october"... why? because October contains the letter 'T', and he botched his ISO date parsing (format: YYYY-MM-DDTHH:mm:ss) by checking the presense of the letter T.. I have many many stories of him commiting some bad code, only to spend 12h in a row trying frantically to correct the bug by adding ifs and elses. The last time I looked at his code, he was rewriting a huffman compression algorithm by himself (NIH syndrome) to compress his on disk data. Complete with loads of code to handle per-bit operations that he wrote b y himself instead of relying on a battle-proof library. Management-wise, they accept his behavior because this guy, working from his own home, often can work at scandalous hours and be on the bridge when he pushes a botched version to production at 2AM. At the time of this comment, his last 4 commits on master are at the following time: 08:57PM, 10:40PM, 12:11PM, 01:02AM I know I'm venting hard, but this guy is probably be the best paid engineer of the company, he is a huge liability IMO, and is present at all-hands meeting maybe once a month. So yeah, why bother coding great code, making sure that your tests and CI are green, when some other guy with a bit more history in the company can get away with doing shitty work and having poor life balance, as long as he shows "commitment" when he botches his software releases. This is really some life-long questioning of mine: should I care about things or should I focus on politics and disregard others. Aren't those on top of the pyramid the more "sharky" people that climbed the ladder not by pure skill but by showing the appropriate (bad) behavior when needed and correctly compartimentalized their own questions about ethics and got away ?
- 8y ago
koonsolo 8y ago
Very senior developers know things that are not intuitive, but very true. So I'll let you in on a few secrets. "Good enough is always good enough". You probably want to do more than good enough. Those developers you talked about, probably knew the amount of quality that was actually needed, no more, no less. Clean code doesn't mean "no bugs" and "good software": - I've seen very cool, popular, money making games that had terrible code (all in 1 C file for example). - I've seen a terrible mess of code, that was practically bug free (because it was running for years in production). And have seen that same code refactored to clean code by a junior (who thought he would 'fix things'), and introduced a lot of bugs (because that is just what happens when you write code, even clean one, even by a senior developer). If you deliver a final product (such as a game for example), that will not need extra features, you can hack stuff in at the end. When you would hack code together at the start, you will shoot yourself in the foot by needing to go through your mess all the time. But when you do this at the end of the project, you can save time by adding in quick hacks. The technical dept that you introduce doesn't need to be paid off. Of course you cannot do this with a long running project. But with a deliverable product go right ahead. The main thing that you have to consider is this: EVERYTHING IS A TRADE-OFF. I see juniors make this mistake all the time, selecting the best programming language, the best VCS, the best whatever. You know, that 'best' thing also has drawbacks. So it's always about making trade-offs, selecting something despite the drawbacks, because of the benefits. General rule: if something only has benefits, it's probably because you didn't figure out the drawbacks yet. How to make the proper trade-offs? Experience ;).
- carlmr 8y ago
  >- I've seen very cool, popular, money making games that had terrible code (all in 1 C file for example). Are you sure that wasn't an optimization to get "LTO" with a non-LTO linker?
  - Asooka 8y ago
    No, in that case you would #include all your .c files in one .c file and compile that for release, but would otherwise work in the usual manner. CMake actually has builtin support for doing just that.
carlmr 8y ago
>And the end-users in many niche industries are used to being shipped garbage, so they're just as happy too. I'm one of the end-users of many terrible B2B products. I'm not happy with them, it's just that the department that buys the software from IBM & Co. doesn't use it. They don't care. But it costs a lot of money in the long run because of bugs and slowness.
Cthulhu_ 8y ago
I think I'm getting to that point as well. I've written some very tidy code back when (~5-10 years ago), but nowadays I'm more and more thinking it doesn't really matter - more than one of the projects I've spent months and years of my life on have already been replaced. Not because it wasn't good, just because an alternative was better for that company (like when they replaced some big java enterprise CMS with just some Wordpress instances recently).
- collyw 8y ago
  Have you ever worked maintenance programming on some legacy software?
knowingathing 8y ago
if you care about people then yes. if you don't then no.
MaxBarraclough 8y ago
I'm reminded of, of all things, WW2 tanks. The Russians built a huge volume of very low-quality tanks, expected to go for only a few hundred miles, and to win through superior numbers. Their crews were poorly trained. The designers suggested easy-win improvements, but the brass blocked the changes as it would have impacted production rates. The Germans built the best-engineered tank the world had ever seen, but its design tradeoffs made it ineffective, and it arrived too late in the war.
- joe_fishfish 8y ago
  Worse is better.
  - crististm 8y ago
    "worse is better" is worse
- qzw 8y ago
  Now for a different context: consider Russian cars vs German cars.
  - int0x80 8y ago
    Also Russian fighter jets vs American/NATO, in the 70s-90s timeframe for example mostly. I love the excercise of comparing the 2 design styles: completetly different aproaches to the same problem, both very effective and elegant. Just looking at the surface (copckits) of it gives one a very good impression of the differences. Really a lot of russian vs american style examples. Also technical (engineering) books for example. Generally russian books where a lot more condensed, raw, pure numbers/formulae etc. American school was a lot more colorful, pictures, graphics, plots, diagrams. There were people that liked better the russian style, however I think the "prettier" one has prevailed. Interesting subject I think.
  - senderista 8y ago
    German cars still suffer from some of the same poor engineering instincts that handicapped their tanks and aircraft in WW2: an emphasis on complex designs, unproven innovations, and theoretical or lab-measured performance rather than simplicity and empirically tested performance and reliability.
laythea 8y ago
There is a very real truth to what you say, and I don't believe it is bad. We don't want golden-polished software. Software that only just does its job, makes the company money, pays the bills, and allows for future improvements where possible/necessary. Lean and mean, then refine (if the bills have been paid). The distinction has to be made between good software and well-written software. It is very possible to have well-written bad software and awfully-written good software. I think realising this, is what makes a junior into a senior. Having the confidence to not always do what that little birdy in your head says :) Customers buy software that solves problems, therefore good software solves problems. Customers buy good software, not well written software. These are not always mutually exclusive.
- hailk 8y ago
  For a long time, I kept pushing deadlines because I wanted to write things the "right way". At the end a code that doesn't reach its destination on time or doesn't do what it should be doing is useless, no matter how well written. A good engineer knows when to obsess over code quality and when to look the other way.
  - laythea 8y ago
    Agree. It helps to cut your software-chops or steer yourself into an industry where software is an overhead, rather than the main product (said in the best possible manner). For example, controller software attached to a turbine engine. What I said above is especially true in those scenarios and is actually quite folly to do more than necessary in the name of software perfection. Plus unnecessary complication hurts brains :)
collyw 8y ago
>just spew large quantities of low-quality code that made the managers just as happy Honestly this is my biggest disappointment as I get better as an engineer. No one except me seems to bother about simplicity, readability, maintainability (Ok a few of my colleagues do).

lwansbrough 8y ago

Seems like you kind of answered your own question. :)

mathw 8y ago

Nah they're not happy, they're just trained to think it's how things have to be.

CathyWest 8y ago
You know that and I know that, but often it's easier said than done to convince them of it. I've had users get indignant because I dared criticise their favourite enterprise bloatware like I insulted their mothers. Even as they themselves were struggling with some misfeature keeping them from doing their actual work. But it does mean that it's easy to exceed their expectations, for example by making the browser back button take the user back to the previous view instead of crashing the entire user session. I tend to try to justify spending time solving technical debt by making development of new dazzling features faster and cheaper, but as long as the users (and more importantly their managers) are sufficiently dazzled if you only throw them a pittance once in a while, that becomes hard to sell.

bengale 8y ago

Pretty much my experience too. I don't think it's ever been worth the time or effort to spend time on writing quality software, the people that smash it out quickly are the ones rewarded. I'm starting to feel like the whole movement for 'software craftsmanship' is making a lot of developers miserable. It's maybe better for them to realise they are not artisans, they are bricklayers. To focus that creative energy on their own projects rather than getting burnt out fighting their managers over writing 'good software'.

tonyedgecombe 8y ago
I don't think you can turn it off like that. There are no Michaelangelos spending their day slapping emulsion on drywall.
- maxerickson 8y ago
  Opportunity is not evenly distributed.
collyw 8y ago
>I'm starting to feel like the whole movement for 'software craftsmanship' is making a lot of developers miserable. Not as miserable as working on some 7 year old system hacked together without any craftsmanship. Plus if its a long term project the maintenance costs must spiral.
- CathyWest 8y ago
  I think the point is that it's better to work on some 7 year old system hacked together without any craftsmanship with the belief that craftsmanship is nonsense and spaghetti code is a legitimate design pattern, than to work on it knowing there is a better way to design software.

danmaz74 8y ago

It depends so much on what you're doing. I've been in situations where junior or mid level devs spend a ridiculous amount of time on details that add almost no business value even in the long term. The best developers from the employer pov understand, depending on the project, which level is good enough.

manasirani 8y ago

https://canmypcrunit.org/horizon-zero-dawn-system-requirements/ https://canmypcrunit.org/horizon-zero-dawn-system-requiremen...

tonyedgecombe 8y ago

The end users aren't happy, they mostly hate the crap that is foisted on them.

TheOtherHobbes 8y ago
Very much this. People have incredibly low expectations of software, so of course the software industry feels no need to push for higher quality. Generally business considerations >> user happiness. Software is primarily shipped to make money. If a shitshow product - it's not hard to name a few - makes money, there is no business feedback loop which will raise quality. Senior devs tend to justify this on the basis of experience, and management justifies it on the basis of shareholder value. In reality it's just cheap, shoddy, dispiriting, and cynical. In a mature industry developers would be able to take pride in making end users happy [1], as opposed to making them frustrated and enraged. [1] Not the same goal as impressing developer peers.
Viliam1234 8y ago
They hate it, but they pay for it. Perhaps you could make something they love instead, but if the production then costs 10x more, and they are only willing to pay 2x more, it does not make sense economically.

xgbi 8y ago

Disclosure: small-ish company (~100 employees) in France You know, I kind of went through the same questioning: at my current company we have an employee that has his niche/historical role on one of the key infrastructure of our product. The guys works from his home and whatever hours, commits 300+ lines per commit (90% of which is unrelated to the commit name, just commenting things or uncommenting others). The code is a spagetti of if else if else, it has monstruous "client specific" code (like: if the current client is this guy, then do that, otherwise for all other clients do this). There's even a load of "if the program runs in test, answer what the test expects, otherwise in prod send something else". Every time I look at the commit tree (a balance of wanting to have fun and wanting to see what is going on), I'm in horror. The guy rewrote the java.lang.string, the java.lang.date, and some other base classe of the language to incorporate his own version of the Date handling. Fun fact, at one point his date parsing code "wasn't happy with october"... why? because October contains the letter 'T', and he botched his ISO date parsing (format: YYYY-MM-DDTHH:mm:ss) by checking the presense of the letter T.. I have many many stories of him commiting some bad code, only to spend 12h in a row trying frantically to correct the bug by adding ifs and elses. The last time I looked at his code, he was rewriting a huffman compression algorithm by himself (NIH syndrome) to compress his on disk data. Complete with loads of code to handle per-bit operations that he wrote b y himself instead of relying on a battle-proof library. Management-wise, they accept his behavior because this guy, working from his own home, often can work at scandalous hours and be on the bridge when he pushes a botched version to production at 2AM. At the time of this comment, his last 4 commits on master are at the following time: 08:57PM, 10:40PM, 12:11PM, 01:02AM I know I'm venting hard, but this guy is probably be the best paid engineer of the company, he is a huge liability IMO, and is present at all-hands meeting maybe once a month. So yeah, why bother coding great code, making sure that your tests and CI are green, when some other guy with a bit more history in the company can get away with doing shitty work and having poor life balance, as long as he shows "commitment" when he botches his software releases. This is really some life-long questioning of mine: should I care about things or should I focus on politics and disregard others. Aren't those on top of the pyramid the more "sharky" people that climbed the ladder not by pure skill but by showing the appropriate (bad) behavior when needed and correctly compartimentalized their own questions about ethics and got away ?

8y ago

koonsolo 8y ago

Very senior developers know things that are not intuitive, but very true. So I'll let you in on a few secrets. "Good enough is always good enough". You probably want to do more than good enough. Those developers you talked about, probably knew the amount of quality that was actually needed, no more, no less. Clean code doesn't mean "no bugs" and "good software": - I've seen very cool, popular, money making games that had terrible code (all in 1 C file for example). - I've seen a terrible mess of code, that was practically bug free (because it was running for years in production). And have seen that same code refactored to clean code by a junior (who thought he would 'fix things'), and introduced a lot of bugs (because that is just what happens when you write code, even clean one, even by a senior developer). If you deliver a final product (such as a game for example), that will not need extra features, you can hack stuff in at the end. When you would hack code together at the start, you will shoot yourself in the foot by needing to go through your mess all the time. But when you do this at the end of the project, you can save time by adding in quick hacks. The technical dept that you introduce doesn't need to be paid off. Of course you cannot do this with a long running project. But with a deliverable product go right ahead. The main thing that you have to consider is this: EVERYTHING IS A TRADE-OFF. I see juniors make this mistake all the time, selecting the best programming language, the best VCS, the best whatever. You know, that 'best' thing also has drawbacks. So it's always about making trade-offs, selecting something despite the drawbacks, because of the benefits. General rule: if something only has benefits, it's probably because you didn't figure out the drawbacks yet. How to make the proper trade-offs? Experience ;).

carlmr 8y ago
>- I've seen very cool, popular, money making games that had terrible code (all in 1 C file for example). Are you sure that wasn't an optimization to get "LTO" with a non-LTO linker?
- Asooka 8y ago
  No, in that case you would #include all your .c files in one .c file and compile that for release, but would otherwise work in the usual manner. CMake actually has builtin support for doing just that.

carlmr 8y ago

>And the end-users in many niche industries are used to being shipped garbage, so they're just as happy too. I'm one of the end-users of many terrible B2B products. I'm not happy with them, it's just that the department that buys the software from IBM & Co. doesn't use it. They don't care. But it costs a lot of money in the long run because of bugs and slowness.

Cthulhu_ 8y ago

I think I'm getting to that point as well. I've written some very tidy code back when (~5-10 years ago), but nowadays I'm more and more thinking it doesn't really matter - more than one of the projects I've spent months and years of my life on have already been replaced. Not because it wasn't good, just because an alternative was better for that company (like when they replaced some big java enterprise CMS with just some Wordpress instances recently).

collyw 8y ago
Have you ever worked maintenance programming on some legacy software?

knowingathing 8y ago

if you care about people then yes. if you don't then no.

MaxBarraclough 8y ago

I'm reminded of, of all things, WW2 tanks. The Russians built a huge volume of very low-quality tanks, expected to go for only a few hundred miles, and to win through superior numbers. Their crews were poorly trained. The designers suggested easy-win improvements, but the brass blocked the changes as it would have impacted production rates. The Germans built the best-engineered tank the world had ever seen, but its design tradeoffs made it ineffective, and it arrived too late in the war.

joe_fishfish 8y ago
Worse is better.
- crististm 8y ago
  "worse is better" is worse
qzw 8y ago
Now for a different context: consider Russian cars vs German cars.
- int0x80 8y ago
  Also Russian fighter jets vs American/NATO, in the 70s-90s timeframe for example mostly. I love the excercise of comparing the 2 design styles: completetly different aproaches to the same problem, both very effective and elegant. Just looking at the surface (copckits) of it gives one a very good impression of the differences. Really a lot of russian vs american style examples. Also technical (engineering) books for example. Generally russian books where a lot more condensed, raw, pure numbers/formulae etc. American school was a lot more colorful, pictures, graphics, plots, diagrams. There were people that liked better the russian style, however I think the "prettier" one has prevailed. Interesting subject I think.
- senderista 8y ago
  German cars still suffer from some of the same poor engineering instincts that handicapped their tanks and aircraft in WW2: an emphasis on complex designs, unproven innovations, and theoretical or lab-measured performance rather than simplicity and empirically tested performance and reliability.

laythea 8y ago

There is a very real truth to what you say, and I don't believe it is bad. We don't want golden-polished software. Software that only just does its job, makes the company money, pays the bills, and allows for future improvements where possible/necessary. Lean and mean, then refine (if the bills have been paid). The distinction has to be made between good software and well-written software. It is very possible to have well-written bad software and awfully-written good software. I think realising this, is what makes a junior into a senior. Having the confidence to not always do what that little birdy in your head says :) Customers buy software that solves problems, therefore good software solves problems. Customers buy good software, not well written software. These are not always mutually exclusive.

hailk 8y ago
For a long time, I kept pushing deadlines because I wanted to write things the "right way". At the end a code that doesn't reach its destination on time or doesn't do what it should be doing is useless, no matter how well written. A good engineer knows when to obsess over code quality and when to look the other way.
- laythea 8y ago
  Agree. It helps to cut your software-chops or steer yourself into an industry where software is an overhead, rather than the main product (said in the best possible manner). For example, controller software attached to a turbine engine. What I said above is especially true in those scenarios and is actually quite folly to do more than necessary in the name of software perfection. Plus unnecessary complication hurts brains :)

collyw 8y ago

>just spew large quantities of low-quality code that made the managers just as happy Honestly this is my biggest disappointment as I get better as an engineer. No one except me seems to bother about simplicity, readability, maintainability (Ok a few of my colleagues do).