Hacker News Reader

Comment by bob1029 | Hacker News Reader

You can fail a project not because you were technically wrong about anything, but because you burned your customer out by taking 6 months instead of 6 weeks to find a viable solution to their problem. Speed is a feature from the perspective of your customers. There is economic value associated with it.

Consider your state of mind when you call the HVAC tech to fix your broken condensing on an August afternoon in Texas. This is how a lot of business leaders feel every day. Speed is the best way to meet uncertainty in complex domains. Unless you are fairly sure you can one shot the problem with a single commit, having a process to iterate with some expediency is important to success.

There is definitely a point where you are going too fast, but the customer will almost certainly let you know when this happens. Let them decide for you how fast is too fast.

View on HN

There are many different types of software customers. A company that contracts an iOS/Android developer to build them an app for an upcoming conference is different from a WalMart that hires developers to build them an e-commerce platform which is also different from a software developer who uses an AWS service who is different from the average Windows or iOS users. All are “software customers”. Yet

> There is definitely a point where you are going too fast, but the customer will almost certainly let you know when this happens. Let them decide for you how fast is too fast.

I don’t really now what customer type that would even be. Is the customer the one controlling the quality or reliability or driving the solution? How would the customer even know you’re “going too fast”? They can’t. They’ll just tell you “everything is half broken all the time, wth?” Is that how they tell you you’re going too fast?

Calling an HVAC tech to fix a broken AC is like an engineer doing a hotfix to alleviate a problem. No one is saying that should take 6 month. A better analogy is expecting the your home builder to build you the house in few days because it’s Texas in August and the sun is too hot outside. Then spending the next 6 years fixing “issues” in the house that was built in a week. Yeah, they didn’t put insulation. Yeah, they run the electrical wiring on the outside. Yeah, the walls aren’t anchored, and plumbing just dumps everything under the house. But at least you’re not in the hot sun.

Of course! The article agrees with you

> Real speed exists. Real speed is what happens when the work is understood, the constraints are clear, the people involved know what they’re doing, and the decisions have been made cleanly enough that execution can happen without constant re-litigation.

I think the article is arguing against speed preventing the kind of planning and alignment that makes smooth delivery possible. Rushing is probably the easiest way to make mistakes that ultimately kill projects, credibility, or at least increase the costs in relational capitol, time and morale. Defaulting to a panicked frenzied state of mind is a perfect way to fail at delivering expedient results.

Depends on the organisation as I've seen the opposite (excessive planning without taking action) too. I'm on the speed side of things nowadays because I was usually wrong when I thought that the "work is understood and the constraints are clear".

Yes, the problem is the feedback loops often don't really exist in the planning stages. It is more difficult to gauge progress. There can be very detailed specifications or plans that won't survive their first contact with reality. This is why waterfall is over with.

Yet - not planning effectively is also a huge problem.

So then the article boils down to, doing things well is good and doing things poorly is bad?

Not arguing against speed, just poorly-executed speed.

If you assign speed-based KPIs to everything, you will get both the good speed and the bad speed.

> Consider your state of mind when you call the HVAC tech to fix your broken condensing on an August afternoon in Texas

And consider your state of mind after the tech came over 6 times in a week, each time claiming to have fixed your HVAC but it keeps breaking.

It seems as if you did not really read the article.

The piece is titled "Religion of Speed" -- in other words speed (or apparent speed) as the guiding principle over anything else.

It says nothing even remotely like "you should take 6 months to do something that can be accomplished in 6 weeks."

And this statement:

"There is definitely a point where you are going too fast, but the customer will almost certainly let you know when this happens. Let them decide for you how fast is too fast"

is baffling to me.

In my experience (40+ years in software development) I have never had a customer/client that would be in a position to have the proper situational awareness + technical depth to make this judgement call.

And even worse I would guess that if even this was not the case that 95% of the time they would not say you're going too fast, instead they would ask to go faster.

I like this argument, but I don't think the article argues against taking urgency into consideration. Do you have anecdotes about companies or people that actually ignore urgency?

I've experienced enough business-critical incidents (or requests) where people across all seniority are just randomly trying stuff, making a mess, without taking time to coordinate, understand the problem, and solve it. It almost always resulted in more overall time and bigger blast radius than if we did it not out of panick.

OTOH my "slow" (I still did things fast, just not purely for the sake of looking fast) and steady approach always took me less time overall to find a proper fix. I also became known as the person who could always find the best possible fix when there's an incident/time constraint, but I also thought that was systematically bad instead of fixing the culture/process.

It's still faster to take a minute (and deep breath), understand the whole problem (incl. urgency and how that affects your solutions), and then solve it. It doesn't mean you can't keep your customers in the loop and assuage their concerns.

Businesses fake urgency all the time. I guess I have never worked in any of these 'high stakes' companies. My whole career, everything was reportedly urgent, but when you missed the deadline, nobody dies, nobody got fired, you just slipped a little and leadership pretended even more urgency. And if you slipped a lot, people got burned out and quit and leadership would institute 'war rooms' and 'crunch time'. And if you slipped a hell of a lot, the project would probably get canceled and the rest of the team was absorbed into various other projects. Nothing matters, the company's stock goes up and down randomly--having nothing to do with your project's failure or success, yet the message from above is always "FAST FAST RUSH URGENT!!!"

It has to be done by next week.

Here it is. It is done.

Great, now we put it on a shelf and ignore it for 6 months.

From my perspective, every time.

Edit: the last time this happened to me, they later revealed that it was going to be shelved for a year.

Don't confuse urgency for FOMO.

> There is definitely a point where you are going too fast, but the customer will almost certainly let you know when this happens.

Usually by stopping doing business with you forever.

> viable solution

Please define viable solution. It's like a piece of string: how long is it? It's a very subjective statement "6 weeks to find a viable solution" - could just as well be 6 months.

Sure you can deliver something that might seem viable and the customer might also a cycle of updates as the viable solution becomes the solution - but how many updates are tolerated and how bad are the problems in the seventh week?

Sure we dumped waterfall for agile and now we live in a constantly updating world of "viable solutions" ...

>but the customer will almost certainly let you know when this happens

The customer won't be able to tell you "you're going too fast", but he will tell you that stuff break. On top of that, because the rate of shipping new features doesn't necessarily match with the rate of usage of said features the moment you'll find out about it will not happen ASAP but probably sometime later, making it even harder to truly know if going fast is the right thing to do in the moment.

> The customer won't be able to tell you "you're going too fast", but he will tell you that stuff break

This is what the GP meant. They won’t spoon feed you the “you’re going too fast”, but they will give you other signals that you can, and would benefit from, interpreting as “you’re going too fast”

Reply on news.ycombinator.com