Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Last 1%

jaredramsey.com

Post reply on HN
Print view View original

81–90 of 93 posts

Re: The Last 1%

#81

Post by HPsquared »

rustybolt wrote: post #78

That last 1% sounds like a godawful lot of work. With this attitude, you can never call something "done", and I deeply hate this notion of "things that are never finished". Like "you are never done learning C++". It implies that everything you do will haunt you for the rest of your life, that everything you do is a liability, and that there is some moral code or obligation to developers to do things because it is con…

I fond it works to have a division of labour between builders and maintainers. Just like in property management, the different phases need a different approach.

Re: The Last 1%

#82

Post by anonymous_sorry »

HPsquared wrote: post #81
rustybolt wrote: post #78

That last 1% sounds like a godawful lot of work. With this attitude, you can never call something "done", and I deeply hate this notion of "things that are never finished". Like "you are never done learning C++". It implies that everything you do will haunt you for the rest of your life, that everything you do is a liability, and that there is some moral code or obligation to developers to do things because it is con…

I fond it works to have a division of labour between builders and maintainers. Just like in property management, the different phases need a different approach.

If builders don't experience the maintenance costs of their decisions, how will they ever learn? And even if they do learn, where's their incentive to do it better next time?

Re: The Last 1%

#83

Post by HPsquared »

anonymous_sorry wrote: post #82
HPsquared wrote: post #81

Earlier quoted context omitted.

I fond it works to have a division of labour between builders and maintainers. Just like in property management, the different phases need a different approach.

If builders don't experience the maintenance costs of their decisions, how will they ever learn? And even if they do learn, where's their incentive to do it better next time?

Communication between the builders and maintainers, including "costly signals" (commercial consequences for poor work, poor reputation, losing contracts etc). There are a lot of builders out there.

Re: The Last 1%

#84

Post by yakkomajuri »

Awfully similar to a post we just had on here: https://news.ycombinator.com/item?id=36967594. Including the fact that both are short and finish with a list of items.

Interestingly neither post seems to be at 100% (not a criticism!), which kinda relates to what I said in the other discussion: https://news.ycombinator.com/item?id=36971378

Re: The Last 1%

#85

Post by FuriouslyAdrift »

anonymous_sorry wrote: post #82
HPsquared wrote: post #81

Earlier quoted context omitted.

I fond it works to have a division of labour between builders and maintainers. Just like in property management, the different phases need a different approach.

If builders don't experience the maintenance costs of their decisions, how will they ever learn? And even if they do learn, where's their incentive to do it better next time?

This is precisely the reason for the existence of SREs... to be able to push back on builders some of the costs and concerns of maintainability.

In the home builders example... that would be lawyers and lawsuits.

Re: The Last 1%

#86

Post by hcarvalhoalves »

anonymous_sorry wrote: post #82
HPsquared wrote: post #81

Earlier quoted context omitted.

I fond it works to have a division of labour between builders and maintainers. Just like in property management, the different phases need a different approach.

If builders don't experience the maintenance costs of their decisions, how will they ever learn? And even if they do learn, where's their incentive to do it better next time?

Maintenance concerns should be part of the requirements for the project to be considered successful, the same as pretty much any other engineering. If the only reason to have SEs care about maintenance is to have them do it later, then incentives are wrong.

Re: The Last 1%

#87

Post by bluefishinit »

huganabaga wrote: post #56
bluefishinit wrote: post #7

None of those things are going to make a bad feature successful and not doing these will not make a good feature unsuccessful. They're all a form of technical debt that should be used very sparingly. Some of them will be more of a distraction than they're worth. Somewhere around 2010 a sort of product development pseudo-science started to take hold of the industry. Telemetry, A/B testing, surveys... oceans began to b…

> ship awesome product and iterate as fast as possible And that attitude is why so much software just sucks. Spending some time to contemplate and test and find out what's good and throw away what's not before it ships, all that goes a long way with quality. "Iterate as fast as possible" is one of those immature ADHD approaches and I'd run if a manager forced my team to do this kind of rushed nonsense.

> Spending some time to contemplate and test and find out what's good and throw away what's not before it ships

Why would you build something to throw away before it ships? Hire good people and they won't build un-shippable crap. "As fast as possible" doesn't mean you rush things, it just means you don't waste time with all these peripheral activities.

Re: The Last 1%

#88

Post by Pxtl »

huganabaga wrote: post #60
Pxtl wrote: post #42

Those don't sound like 1%. They sound like a lot more than that. Which is why they don't get done. Who has the time?

Everybody has time to write an automated test. If you don't, then you don't have time to write code in the first place. That's the difference between professional software engineering and just hacking something quick in your free time. You wouldn't ride a motorbike at 150mph on a German autobahn if it was put together by your neighbor with parts from a junkyard in an afternoon. Unclear to me why you'd treat software…

Fair, automated tests are important, but it's still ludicrous to call automated testing "1%". It's a lot. And let's be real - there isn't always the time, requirements being what they are, especially for properly isolated unit tests. But I'm always an advocate for a "worse-is-better" integration-test-script that requires a full test environment rather than having to build a full mock architecture. Unit tests are the gold standard, but a few integration tests per-feature are a good bare minimum.

Re: The Last 1%

#89

Post by lacoolj »

screw all that stuff for now and ship it :)

seriously tho, that stuff is very important and should get some priority but only after you have customers. if you are not in a position to worry about revenue (maybe you won the lottery or this is a project backed by Google), then do as many of those things beforehand as you can. but your hardest sale is the first one, which will be even harder the longer you wait to put it on the market.

Re: The Last 1%

#90

Post by huganabaga »

bluefishinit wrote: post #87
huganabaga wrote: post #56

Earlier quoted context omitted.

> ship awesome product and iterate as fast as possible And that attitude is why so much software just sucks. Spending some time to contemplate and test and find out what's good and throw away what's not before it ships, all that goes a long way with quality. "Iterate as fast as possible" is one of those immature ADHD approaches and I'd run if a manager forced my team to do this kind of rushed nonsense.

> Spending some time to contemplate and test and find out what's good and throw away what's not before it ships Why would you build something to throw away before it ships? Hire good people and they won't build un-shippable crap. "As fast as possible" doesn't mean you rush things, it just means you don't waste time with all these peripheral activities.

> Why would you build something to throw away before it ships?

That's because you learn things along the way. About underspecified requirements, about design choices that looked good on paper but ended up brittle, about tech that promised something but couldn't hold up to it when tested out thoroughly. There are many reasons and in every field you see this effect.

> Hire good people and they won't build un-shippable crap

Ever heard of a prototype? Those exist for a reason.

Post reply on HN