Hacker News Reader

Comment by lostcolony | Hacker News Reader

'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).

View on HN

> “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.

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.

> 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.

Ok, how about this:

We spend so much time claiming to fight against perfectionism, and then we invite it right back in by framing important questions badly.

Go, be wrong, and then be less wrong as quickly as you can.

Author here: nice comment. Absolutely the way to success isn't about avoiding all risk. As you point out, this is the way to mediocrity and tedium.

Life (and software) should be about taking risks - I've written a bunch of articles about this on the site[1] about how development is about making bets.

[1] - https://riskfirst.org/Coding-Bets

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.

It's not about blame. It's about recognizing where to fix the problem.

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.

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

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.

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.

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.

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.

Reply on news.ycombinator.com