5 ms·

> If we invert software development, the goal isn’t then to write code that works, it’s spending time on avoiding writing poor quality code and bugs. This line

> If we invert software development, the goal isn’t then to write code that works, it’s spending time on avoiding writing poor quality code and bugs. This line is packaged to sound really insightful, but is it? The goal of software development is to create software in support of some greater mission. That mission might be to make someone's life easier, to make money, to advance human knowledge, or many other things. If I write no software today, I've also written no new bugs. But have I made any progress toward achieving the mission? Feels like this person is very frustrated with novice engineers writing buggy code and has assumed a gatekeeper role to protect the integrity of the codebases in which he holds responsibility. It may be a necessary role at his organization, but I just don't agree with the cynical and depressing message.

eithed 6y ago
I understand where you're coming from, but I'd read it as writing code that will behave the way it's anticipated without any gotchas - merely writing code that works in a specific scenario shouldn't be the goal. Additional benefit would be to write code that easily extendable, but that's not mentioned here.
eplanit 6y ago
Did Deepak Chopra write the article? It's like "when you're nowhere you're 'now here'". It seems so clever... at first.
protonimitate 6y ago
Agreed - this article reads like a "get good" message to "amateurs". Which, sure, you should be striving for constant improvement - but if you work in an environment where sloppy/quick work is incentivized I would argue it's the responsibility of the "professional" to push back and set up an environment for success. Blaming all your issues on more junior members of the team is a huge red flag, and this article doesn't really offer any insight into how to bridge the gap between "amateur" and "professional" (which, imo, falls on the senior members of the team).
- hoskinator 6y ago
  I agree junior members should be helped. Lots of developers have a cowboy approach but they aren't junior. Senior members should set and enforce the standards via best practices, code reviews and setting the definition of done e.g. unit tests, data, deployable etc
duxup 6y ago
I always read these and wonder "So uh, did you go and talk to the guy and help him out?" Now maybe they did and the other person refuses to listen (not common in my experience), but I always wonder... you can't just make up 'rules' and expect folks to magically write good code because they followed a rule.
slowwriter 6y ago
I feel like it’s the word ‘goal’ that makes one stumble here. I agree that he is not really describing the ‘goal’ of software development. He’s describing how to succeed at software development in order to reach a larger goal. And although it took me a while to understand what the author is getting at, I do kind of see his point which in my mind could be summarized as: slow and steady wins the race. Or: In order to speed up (in the long run), slow down (in the short term). Be conservative, be thorough, understand that developer productivity isn’t about that LOC per x unit of time. One analogy that comes to mind for me is Formula 1. Sure, it would be faster, right now, to just not pit. You would have to drive into the pit, stop and wait for the tyres to be changed and drive out again. Meanwhile your opponents are zooming past you out on the track. But if you don’t pit, soon enough your tyres will be worn down and it becomes impossible to keep heat and performance in them, and after a while longer you might even have to stop completely due to a puncture. The ‘pitstop’ could be anything that ensures productivity in the long term and as such helps in reaching the final goal, and those are the things that take a professional to understand the importance of.
commandlinefan 6y ago
> The goal of software development is to create software in support of some greater mission If that's the goal - the only goal - then all code is equal, and it doesn't matter how it's written. So... go crazy? Use global variables and goto statements? Hardcode path names and don't bother with build scripts? Writing software that works is challenging, but writing software that can be safely modified is even more so.
- NortySpock 6y ago
  Right, but in most cases, supporting a greater mission is a marathon, not a sprint, so bad code in an early version is very painful later, and detracts from the long term mission. You gotta think long term (usually)
- Raidion 6y ago
  I mean, if the only requirement is "have software that works", yea, go nuts. Look at a ton of tech demos, working is the goa the goal, the code sucks, it's fine, it's gonna be rewritten anyway. Practically the requirements are "have software that works, and will be sustainably developed and improved for 5 years". Making the trade offs in terms of "perfect code" to "good enough code" is what makes a software developer (in most settings) go from "good" to "great". Good software engineers can see all the edge cases and future paths. Great software engineers can prioritize those against business goals. Just like "global variables and goto statements" is bad, so is "perfect, provably correct, and overtested" code in the vast majority of business settings.
scottious 6y ago
I think you're right, but I also think the author isn't necessarily wrong. Using his tennis analogy, each chunk of code written is like swinging at the tennis ball. You don't have to have the perfect curve-ball, you just have to NOT screw it up. I've too often seen developers try to attack the ball with the perfect swing and the most force possible, only to have it go straight into the net. If they just focused on getting it over the net as simply as possible, the end result usually means less code that's easier to understand. Example: junior dev needs to write a data transformation pipeline. They write a microservice and deploy it in Docker on Kubernetes. They do a lot of hand-wringing about reactive design and non-blocking I/O. They end up wrestling with the deploy and getting it done on time. All it needed to be was a simple single-threaded command line utility. In 15 years, I've seen this story play out tons of times... I'm basically watching devs trip over themselves. I'm not saying I'm perfect either, this has happened to me too.
- justin_oaks 6y ago
  This reminds me of advice I give to junior devs who over-complicate things in the planning phase: "Start with the stupidest thing that will work". You need to make something work before you can make it work well. You need to start simple before you dig into the complexity. Sometimes you find that the "stupid" solution is good enough.
  - tsimionescu 6y ago
    I think it's important to note here that you need to start your thinking or design from the simplest possible solution, but that doesn't mean it always makes sense to actually implememt that solution.
    - justin_oaks 6y ago
      Agreed. That's why I advise to start simple/stupid, not necessarily deploy the stupid solution. It's a direct response to those who start out with crazy-complicated schemes in mind.
  - 6y ago
varispeed 6y ago
What is the alternative? If you let shoddy code in, it is difficult to get rid of and it may become a foundation for even shoddier one (if you let that in, then why you won't let this in).
potatoz2 6y ago
I didn't read the article the same way. I think we're all, in a certain way, amateurs, at least in some cases: when we're rushed, stressed, distracted, or all three. As a project accumulates people working on it and, crucially, as existing code is modified and added to, the probability that you'll introduce a bug approaches 1. I think the article is saying we should focus on tooling that makes natural human errors less likely, instead of trying to focus on writing more code: in other words, write less code, ship it once without errors, instead of writing more code and having to go through the dev to prod feedback loop repeatedly. The tooling that helps you do that are DevOps practices, testing (and testability), simpler/more conservative design, and some time spent thinking about how to construct the software (or reconstruct it, when modifications are needed).
908B64B197 6y ago
> Feels like this person is very frustrated with novice engineers writing buggy code and has assumed a gatekeeper role to protect the integrity of the codebases in which he holds responsibility. I wonder what his recruitment pipeline looks like where 80% of engineers end up not being productive. Sounds like he's hiring wrong to begin with.

eithed 6y ago

I understand where you're coming from, but I'd read it as writing code that will behave the way it's anticipated without any gotchas - merely writing code that works in a specific scenario shouldn't be the goal. Additional benefit would be to write code that easily extendable, but that's not mentioned here.

eplanit 6y ago

Did Deepak Chopra write the article? It's like "when you're nowhere you're 'now here'". It seems so clever... at first.

protonimitate 6y ago

Agreed - this article reads like a "get good" message to "amateurs". Which, sure, you should be striving for constant improvement - but if you work in an environment where sloppy/quick work is incentivized I would argue it's the responsibility of the "professional" to push back and set up an environment for success. Blaming all your issues on more junior members of the team is a huge red flag, and this article doesn't really offer any insight into how to bridge the gap between "amateur" and "professional" (which, imo, falls on the senior members of the team).

hoskinator 6y ago
I agree junior members should be helped. Lots of developers have a cowboy approach but they aren't junior. Senior members should set and enforce the standards via best practices, code reviews and setting the definition of done e.g. unit tests, data, deployable etc

duxup 6y ago

I always read these and wonder "So uh, did you go and talk to the guy and help him out?" Now maybe they did and the other person refuses to listen (not common in my experience), but I always wonder... you can't just make up 'rules' and expect folks to magically write good code because they followed a rule.

slowwriter 6y ago

I feel like it’s the word ‘goal’ that makes one stumble here. I agree that he is not really describing the ‘goal’ of software development. He’s describing how to succeed at software development in order to reach a larger goal. And although it took me a while to understand what the author is getting at, I do kind of see his point which in my mind could be summarized as: slow and steady wins the race. Or: In order to speed up (in the long run), slow down (in the short term). Be conservative, be thorough, understand that developer productivity isn’t about that LOC per x unit of time. One analogy that comes to mind for me is Formula 1. Sure, it would be faster, right now, to just not pit. You would have to drive into the pit, stop and wait for the tyres to be changed and drive out again. Meanwhile your opponents are zooming past you out on the track. But if you don’t pit, soon enough your tyres will be worn down and it becomes impossible to keep heat and performance in them, and after a while longer you might even have to stop completely due to a puncture. The ‘pitstop’ could be anything that ensures productivity in the long term and as such helps in reaching the final goal, and those are the things that take a professional to understand the importance of.

commandlinefan 6y ago

> The goal of software development is to create software in support of some greater mission If that's the goal - the only goal - then all code is equal, and it doesn't matter how it's written. So... go crazy? Use global variables and goto statements? Hardcode path names and don't bother with build scripts? Writing software that works is challenging, but writing software that can be safely modified is even more so.

NortySpock 6y ago
Right, but in most cases, supporting a greater mission is a marathon, not a sprint, so bad code in an early version is very painful later, and detracts from the long term mission. You gotta think long term (usually)
Raidion 6y ago
I mean, if the only requirement is "have software that works", yea, go nuts. Look at a ton of tech demos, working is the goa the goal, the code sucks, it's fine, it's gonna be rewritten anyway. Practically the requirements are "have software that works, and will be sustainably developed and improved for 5 years". Making the trade offs in terms of "perfect code" to "good enough code" is what makes a software developer (in most settings) go from "good" to "great". Good software engineers can see all the edge cases and future paths. Great software engineers can prioritize those against business goals. Just like "global variables and goto statements" is bad, so is "perfect, provably correct, and overtested" code in the vast majority of business settings.

scottious 6y ago

I think you're right, but I also think the author isn't necessarily wrong. Using his tennis analogy, each chunk of code written is like swinging at the tennis ball. You don't have to have the perfect curve-ball, you just have to NOT screw it up. I've too often seen developers try to attack the ball with the perfect swing and the most force possible, only to have it go straight into the net. If they just focused on getting it over the net as simply as possible, the end result usually means less code that's easier to understand. Example: junior dev needs to write a data transformation pipeline. They write a microservice and deploy it in Docker on Kubernetes. They do a lot of hand-wringing about reactive design and non-blocking I/O. They end up wrestling with the deploy and getting it done on time. All it needed to be was a simple single-threaded command line utility. In 15 years, I've seen this story play out tons of times... I'm basically watching devs trip over themselves. I'm not saying I'm perfect either, this has happened to me too.

justin_oaks 6y ago
This reminds me of advice I give to junior devs who over-complicate things in the planning phase: "Start with the stupidest thing that will work". You need to make something work before you can make it work well. You need to start simple before you dig into the complexity. Sometimes you find that the "stupid" solution is good enough.
- tsimionescu 6y ago
  I think it's important to note here that you need to start your thinking or design from the simplest possible solution, but that doesn't mean it always makes sense to actually implememt that solution.
  - justin_oaks 6y ago
    Agreed. That's why I advise to start simple/stupid, not necessarily deploy the stupid solution. It's a direct response to those who start out with crazy-complicated schemes in mind.
- 6y ago

varispeed 6y ago

What is the alternative? If you let shoddy code in, it is difficult to get rid of and it may become a foundation for even shoddier one (if you let that in, then why you won't let this in).

potatoz2 6y ago

I didn't read the article the same way. I think we're all, in a certain way, amateurs, at least in some cases: when we're rushed, stressed, distracted, or all three. As a project accumulates people working on it and, crucially, as existing code is modified and added to, the probability that you'll introduce a bug approaches 1. I think the article is saying we should focus on tooling that makes natural human errors less likely, instead of trying to focus on writing more code: in other words, write less code, ship it once without errors, instead of writing more code and having to go through the dev to prod feedback loop repeatedly. The tooling that helps you do that are DevOps practices, testing (and testability), simpler/more conservative design, and some time spent thinking about how to construct the software (or reconstruct it, when modifications are needed).

908B64B197 6y ago

> Feels like this person is very frustrated with novice engineers writing buggy code and has assumed a gatekeeper role to protect the integrity of the codebases in which he holds responsibility. I wonder what his recruitment pipeline looks like where 80% of engineers end up not being productive. Sounds like he's hiring wrong to begin with.