3 ms·

The goal of writing software is rarely to produce a piece of well-engineered software. More commonly, the goal is to produce a product in a given time frame usi

The goal of writing software is rarely to produce a piece of well-engineered software. More commonly, the goal is to produce a product in a given time frame using the team of engineers available, which may be of variable quality. If you’re trying to make the software perfect, you’re likely doing something very wrong.

hinkley 5y ago
Businesses are in business to stay in business. Frequently nobody notices how much decline in capability the team is struggling with because 1) the change comes slowly, and 2) people are getting 'better' at taking calculated risks that keep the tempo up, masking the real situation until the company hits a brick wall and all estimates go from 3 weeks to 3 months overnight. As a customer these sorts of changes in behavior are hard to accommodate. It's almost always better to set an expectation that things take just a little bit longer than the customer would prefer but the software actually works when we do get it. When you have a date driven 'emergency' you deliver a small increment that handles the particular situation the customer actually has. Everyone mistakes wants for needs. When you foster that then you become part of a codependent relationship at best, exploitative at worst. Also if you swoop in and clean up everyone else's mess every time, they never experience any backpressure and you end up burning yourself out while they learn absolutely nothing. See earlier reference to The Power of No.
- CRConrad 5y ago
  > Businesses are in business to stay in business. Most of them do that quite regardless of whether they have any integrity or not.
- chrisweekly 5y ago
  Well said. (Bummed to find no profile info like a twitter handle or blog; if you've got one you're willing to share, please LMK.)
chrisweekly 5y ago
I agree that striving for (let alone expecting) perfection is fraught. But a business's goals in commissioning software development are related to but distinct from a developer's goals in delivering it. If you write software for a living in the 21st century, and you don't find a way to incorporate constant learning and improvement, and strive to refine and master your craft, then you're definitely doing it wrong.
knighthack 5y ago
> If you're trying to make the software perfect, you're likely doing something very wrong. ...Tell that to the programmers writing robust, highly-tested systems for aerospace/flight applications, which have to be designed to be as safe/'perfect' as that can be, since mistakes can not only cost millions, but be directly fatal to end users. I can accept the proposition that the general commercial end goal of software development is the product, rather than a _perfect_ product. But your claim that one's striving to achieve perfection in software is "very wrong" is a questionable statement, and ignorant of the 'engineering' aspect of software development.
- hinkley 5y ago
  I will say that as I've gotten older that I've noticed a bigger link between code others may think I'm obsessing over and job satisfaction. If I'm insisting on 'perfection' in a bit of code, coping mechanisms are definitely part of the mix. I think only twice has it come to the point of me saying "If you want it to work that way, you're going to need to find someone else to work on this," but I have definitely felt it more often than that. It feels foolish to say it but sometimes honesty is the most efficient form of communication. If you don't let your engineers take out some of their frustrations on the code, they will take it out on someone else. Some of your 'inefficiency' is bridge-building. Like any other relationship, sometimes you have to humor the other person with requests that seem unimportant to you. In fact most service businesses are built on that mismatch - you want something to happen but you hate doing it and it's worth $N an hour to get someone else to do it, while I hate it less and $N/2 an hour sounds like a pretty reasonable incentive to do it for you. But part of my complaint here is discovering a class of people who talk the talk about how they wish they could do something, but the moment the backlog empties out they sit around saying there's nothing to work on. The first time I encountered this, and started to wonder how many bullshitters there were at the current place, I was furious. Because for once in a blue moon integrity actually was on the schedule, and I discovered people who had none. And of course this could not be a unique situation I was in. How many other people had been saying pretty words they didn't mean my entire career? That was, all told, probably one of the worst days in my career. Being laid off is always the worst after it happens, but when you land in something better that starts to fade. Meanwhile this experience is just there. Some days it's worse, others it's better, but my life was easier when I thought everyone was just doing the best they could.
jdmichal 5y ago
This is basically fixed-time vs fixed-scope. You're detailing fixed-time, but fixed-scope projects do also exist.

hinkley 5y ago

Businesses are in business to stay in business. Frequently nobody notices how much decline in capability the team is struggling with because 1) the change comes slowly, and 2) people are getting 'better' at taking calculated risks that keep the tempo up, masking the real situation until the company hits a brick wall and all estimates go from 3 weeks to 3 months overnight. As a customer these sorts of changes in behavior are hard to accommodate. It's almost always better to set an expectation that things take just a little bit longer than the customer would prefer but the software actually works when we do get it. When you have a date driven 'emergency' you deliver a small increment that handles the particular situation the customer actually has. Everyone mistakes wants for needs. When you foster that then you become part of a codependent relationship at best, exploitative at worst. Also if you swoop in and clean up everyone else's mess every time, they never experience any backpressure and you end up burning yourself out while they learn absolutely nothing. See earlier reference to The Power of No.

CRConrad 5y ago
> Businesses are in business to stay in business. Most of them do that quite regardless of whether they have any integrity or not.
chrisweekly 5y ago
Well said. (Bummed to find no profile info like a twitter handle or blog; if you've got one you're willing to share, please LMK.)

chrisweekly 5y ago

I agree that striving for (let alone expecting) perfection is fraught. But a business's goals in commissioning software development are related to but distinct from a developer's goals in delivering it. If you write software for a living in the 21st century, and you don't find a way to incorporate constant learning and improvement, and strive to refine and master your craft, then you're definitely doing it wrong.

knighthack 5y ago

> If you're trying to make the software perfect, you're likely doing something very wrong. ...Tell that to the programmers writing robust, highly-tested systems for aerospace/flight applications, which have to be designed to be as safe/'perfect' as that can be, since mistakes can not only cost millions, but be directly fatal to end users. I can accept the proposition that the general commercial end goal of software development is the product, rather than a _perfect_ product. But your claim that one's striving to achieve perfection in software is "very wrong" is a questionable statement, and ignorant of the 'engineering' aspect of software development.

hinkley 5y ago
I will say that as I've gotten older that I've noticed a bigger link between code others may think I'm obsessing over and job satisfaction. If I'm insisting on 'perfection' in a bit of code, coping mechanisms are definitely part of the mix. I think only twice has it come to the point of me saying "If you want it to work that way, you're going to need to find someone else to work on this," but I have definitely felt it more often than that. It feels foolish to say it but sometimes honesty is the most efficient form of communication. If you don't let your engineers take out some of their frustrations on the code, they will take it out on someone else. Some of your 'inefficiency' is bridge-building. Like any other relationship, sometimes you have to humor the other person with requests that seem unimportant to you. In fact most service businesses are built on that mismatch - you want something to happen but you hate doing it and it's worth $N an hour to get someone else to do it, while I hate it less and $N/2 an hour sounds like a pretty reasonable incentive to do it for you. But part of my complaint here is discovering a class of people who talk the talk about how they wish they could do something, but the moment the backlog empties out they sit around saying there's nothing to work on. The first time I encountered this, and started to wonder how many bullshitters there were at the current place, I was furious. Because for once in a blue moon integrity actually was on the schedule, and I discovered people who had none. And of course this could not be a unique situation I was in. How many other people had been saying pretty words they didn't mean my entire career? That was, all told, probably one of the worst days in my career. Being laid off is always the worst after it happens, but when you land in something better that starts to fade. Meanwhile this experience is just there. Some days it's worse, others it's better, but my life was easier when I thought everyone was just doing the best they could.

jdmichal 5y ago

This is basically fixed-time vs fixed-scope. You're detailing fixed-time, but fixed-scope projects do also exist.