4 ms·

'How can we, as software developers, minimise the chance of building the wrong thing?' Make sure you're hiring the right product people? I've never "built the

'How can we, as software developers, minimise the chance of building the wrong thing?' Make sure you're hiring the right product people? I've never "built the wrong thing"; I -have- been told to solve the wrong problem, or been given incorrect information, or been left with unresolvable ambiguities from product that I've just had to arbitrarily pick between. That may seem like a picky distinction, but it matters. I've never gone back and said "Huh, yeah, you defined the problem really well, then were super responsive with my following up with you, but I somehow wrote code that did something completely different to what we specced out together". Invariably it's been product not knowing what they actually want, or being hellbent to build something stupid (massive amounts of effort for no revenue impact, etc).

hackbinary 7y ago
Honestly, Project/Product/Program staff, BAs, and Testers perform an important function when properly aligned and cooperating with development staff. When done well, they keep pesky 'business side's owners out of the way so the technical workers can get on with development work.
bobm_kite9 7y ago
Isn't it still the wrong thing, even if you built exactly what was asked for?
eberyvody 7y ago
never have i ever been involved with a _successful_ software project where product decisions were made entirely by product people and handed off to design/eng. in my limited experience, good product builders exploit leverage points that in order to solve customer problems / test assumptions quickly. for example, usually the product people don't know how flow X is really easy to restructure like Y and solve the same problem. kind of related, but pushing all the speccing responsibility to product is also kind of boring for me as an IC.
- Ididntdothis 7y ago
  Yes, people have to work together and all roles have something important to contribute. I have been in plenty of situations where product managers and users tried to solve a problem and I could guide the discussion towards solutions that made sense development wise and also satisfied the users. Having customers or product people defining solutions alone is a surefire recipe for misdesigned systems.
hinkley 7y ago
> “How can we, as software developers, minimise the chance of building the wrong thing?” I had an immediate histamine reaction to this statement. With a site title like Risk First, it’s like he’s standing right next to the solution but looking the other way. I suppose we’ll see in the next article if he’s being coy setting up a scenario so he can make a dramatic turn or not. I’m worried he’s instead being sincere. But that question? It’s so much the wrong question. We know from surveys that couching questions the wrong way invites certain answers and precludes others. So I have some questions of my own, that are biased toward my agenda. Who cares if you built the wrong thing? Or more informatively, why do you care that you built the wrong thing? Is it because you were wrong? Oh boo boo. This is a trap intellectuals set for themselves all the time. You want to know the stuff I recall from school? It’s often the stuff I got wrong on the test. I get it. It’s a bad feeling. But bad feelings aren’t automatically bad. There are worse things in life and software than bad feelings. Like hollowness. A grey heckscape of empty mediocrity teaches you almost nothing and doesn’t even leave you with a story to tell. Nothing happened at all, and it was horrible. How do we, as software developers, minimise our investment (time, energy, mindshare) in building the wrong thing? That’s a much better question. And some times it means steering toward the stupid, or the crazy, instead of just being averse. Steering past it, not away from it.
- haolez 7y ago
  I could understand the author's idea with absolute clarity (regardless of his merit). I don't have the slightest idea of what I've just read in your comment.
  - rumanator 7y ago
    > I don't have the slightest idea of what I've just read in your comment. Easy. Not having your way does not mean that you're building the wrong thing, and feeling bad because your idea didn't prevailed is not a technical problem nor a sign that everyone else is incompetent or that the process is faulty. In fact, it just mean that the complainer is unprofessional and immature.
  - hinkley 7y ago
luckyscs 7y ago
The triangle relationship between product Design <-> Product <-> Engineering seems so hard to get right and maintain. You need experts that can straddle these lines and make sure each branch is on the same page and their concerns are appropriatly attended to, regarding the needs of a business. I hate blaming others, it's hard to enact productive solutions when battling against people you need to work with, I like blaming lack of processes. How do we as engineers guide the most efficient solutions for the business problems, and in turn make our product development effective, nimble, less wasteful. I for one have really focused on developing process around design and engineering communications. It seems harder to make an impact between dev and product or design and product, often there is an imbalance of power and that branch is the executive and can order some really dumb and wasteful decisions if they don't have proper consult with and respect towards the other branches.
deleted 7y ago
[deleted]
mobjack 7y ago
It is not realistic to expect product to be 100% correct. Software is an iterative process and it takes some trial and error to get it in a good state. I always expect product to be wrong about something so it is my job to help identify issues early and plan for the specs to change.
boublepop 7y ago
Sounds like you saying that the wrong thing has indeed been built in a project where you where doing the building, but you are in a great position to blame someone else for any bad products that resulted since they asked for the wrong thing or where vague. Personally I’d say that I don’t care who’s fault it is if the product ends out bad, no one wins anything from playing the blame game, either you fix the process or you repeat the mistakes. This is why I want fast release cycles validating assumptions with end-users. Of cause there’s going to be problems in specs, don’t sit back and claim that you never had any bugs in your code ever! But the question is how do you push forwards knowing for sure that some assumptions are wrong, and that some are unneeded. Well it’s not a huge surprise, you test! Release feature incrementally with minimal work put in. Then you iterate on that. Your reviews are unit-tests for stakeholders and releases are integration tests into end-users. Doing a big waterfall product only to then stand back from a huge tire fire saying “yea, but the root problem was that the users asked for the wrong thing in the requirements”. That’s just not me.
- lostcolony 7y ago
  It's not about blame. It's about recognizing where to fix the problem.

hackbinary 7y ago

Honestly, Project/Product/Program staff, BAs, and Testers perform an important function when properly aligned and cooperating with development staff. When done well, they keep pesky 'business side's owners out of the way so the technical workers can get on with development work.

bobm_kite9 7y ago

Isn't it still the wrong thing, even if you built exactly what was asked for?

eberyvody 7y ago

never have i ever been involved with a _successful_ software project where product decisions were made entirely by product people and handed off to design/eng. in my limited experience, good product builders exploit leverage points that in order to solve customer problems / test assumptions quickly. for example, usually the product people don't know how flow X is really easy to restructure like Y and solve the same problem. kind of related, but pushing all the speccing responsibility to product is also kind of boring for me as an IC.

Ididntdothis 7y ago
Yes, people have to work together and all roles have something important to contribute. I have been in plenty of situations where product managers and users tried to solve a problem and I could guide the discussion towards solutions that made sense development wise and also satisfied the users. Having customers or product people defining solutions alone is a surefire recipe for misdesigned systems.

hinkley 7y ago

> “How can we, as software developers, minimise the chance of building the wrong thing?” I had an immediate histamine reaction to this statement. With a site title like Risk First, it’s like he’s standing right next to the solution but looking the other way. I suppose we’ll see in the next article if he’s being coy setting up a scenario so he can make a dramatic turn or not. I’m worried he’s instead being sincere. But that question? It’s so much the wrong question. We know from surveys that couching questions the wrong way invites certain answers and precludes others. So I have some questions of my own, that are biased toward my agenda. Who cares if you built the wrong thing? Or more informatively, why do you care that you built the wrong thing? Is it because you were wrong? Oh boo boo. This is a trap intellectuals set for themselves all the time. You want to know the stuff I recall from school? It’s often the stuff I got wrong on the test. I get it. It’s a bad feeling. But bad feelings aren’t automatically bad. There are worse things in life and software than bad feelings. Like hollowness. A grey heckscape of empty mediocrity teaches you almost nothing and doesn’t even leave you with a story to tell. Nothing happened at all, and it was horrible. How do we, as software developers, minimise our investment (time, energy, mindshare) in building the wrong thing? That’s a much better question. And some times it means steering toward the stupid, or the crazy, instead of just being averse. Steering past it, not away from it.

haolez 7y ago
I could understand the author's idea with absolute clarity (regardless of his merit). I don't have the slightest idea of what I've just read in your comment.
- rumanator 7y ago
  > I don't have the slightest idea of what I've just read in your comment. Easy. Not having your way does not mean that you're building the wrong thing, and feeling bad because your idea didn't prevailed is not a technical problem nor a sign that everyone else is incompetent or that the process is faulty. In fact, it just mean that the complainer is unprofessional and immature.
- hinkley 7y ago

luckyscs 7y ago

The triangle relationship between product Design <-> Product <-> Engineering seems so hard to get right and maintain. You need experts that can straddle these lines and make sure each branch is on the same page and their concerns are appropriatly attended to, regarding the needs of a business. I hate blaming others, it's hard to enact productive solutions when battling against people you need to work with, I like blaming lack of processes. How do we as engineers guide the most efficient solutions for the business problems, and in turn make our product development effective, nimble, less wasteful. I for one have really focused on developing process around design and engineering communications. It seems harder to make an impact between dev and product or design and product, often there is an imbalance of power and that branch is the executive and can order some really dumb and wasteful decisions if they don't have proper consult with and respect towards the other branches.

deleted 7y ago

[deleted]

mobjack 7y ago

It is not realistic to expect product to be 100% correct. Software is an iterative process and it takes some trial and error to get it in a good state. I always expect product to be wrong about something so it is my job to help identify issues early and plan for the specs to change.

boublepop 7y ago

Sounds like you saying that the wrong thing has indeed been built in a project where you where doing the building, but you are in a great position to blame someone else for any bad products that resulted since they asked for the wrong thing or where vague. Personally I’d say that I don’t care who’s fault it is if the product ends out bad, no one wins anything from playing the blame game, either you fix the process or you repeat the mistakes. This is why I want fast release cycles validating assumptions with end-users. Of cause there’s going to be problems in specs, don’t sit back and claim that you never had any bugs in your code ever! But the question is how do you push forwards knowing for sure that some assumptions are wrong, and that some are unneeded. Well it’s not a huge surprise, you test! Release feature incrementally with minimal work put in. Then you iterate on that. Your reviews are unit-tests for stakeholders and releases are integration tests into end-users. Doing a big waterfall product only to then stand back from a huge tire fire saying “yea, but the root problem was that the users asked for the wrong thing in the requirements”. That’s just not me.

lostcolony 7y ago
It's not about blame. It's about recognizing where to fix the problem.