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

Throwing away 18 months of code and starting over

tompiagg.io

Post reply on HN
Print view View original

61–70 of 89 posts

Re: Throwing away 18 months of code and starting over

#61

Post by ordu »

andrewstuart wrote: post #3

I wouldn’t admit to this level of frankly incompetence. Wildly swinging dogmatism on how to do software development that’s so wrong you have to throw it all away - then repeating this failure loop multiple times. Doesn’t inspire any confidence in the person I wouldn’t get them to lead a project. Why would you be so loud and proud about all this.

> I wouldn’t admit to this level of frankly incompetence.

Well yeah. It reminds me of how I wrote an addon for WoW, while having no clue how to write GUI code, learning lua and Blizzard API as I go, and having no tools except a text editor. It took 3-4 sharp ideological shifts, till I got to reading about elm architecture, and refactored all the code into it, while using addons helping with debugging issues, using a scaffold to create throw away addons for testing details of how WoW API functions/object work, using Ace library for messages and some other things, using my another addon to track events to learn when and which events WoW fires... Near the end I was a pretty competent addon developer, but the most part of my way there I was just trying a lot of things to see what works.

> Why would you be so loud and proud about all this.

Oh, I also like to tell my story of how it was. When I finally got it work on clean elm architecture with clear separation of state, view and update, I was proud, obviously, but even before that I was proud because of Danning-Kruger. My code was a way better than the original addon, and it was becoming better and better with each sharp turn. It is funny in hindsight.

Re: Throwing away 18 months of code and starting over

#62

Post by hinkley »

oraphalous wrote: post #60
hinkley wrote: post #56

Earlier quoted context omitted.

What ends up happening is that your most fundamental features end up rotting because manual testing has biases. Chief among them is probably Recency Bias. It is in fact super easy to break a launch feature if it’s not gating any of the features you’re working on now. If you don’t automate those, yes, you’re nuts. One of the worst ones I ever encountered was learning that someone broke the entire help system three mon…

I think maybe - this conversation is more about giving some more acknowledgement to the other side of this issue. It's not that I disagree with you essentially - or particularly with respect to your analysis of your specific examples. 100% in the cases you describe. Those sound like beneficial tests. Particularly because your example SPEAKS to the business case - users were using the help docs (I think you mean users…

There is supposedly a famous video series of Uncle Bob trying and failing to solve sudoku with TDD. He did not read any guides on solving it and tried from first principles instead, and bounced off of it.

It’s clear to me that if you don’t know what you’re building, testing it first has rubber duck value that can easily be overshadowed by Sunk Cost. I always test my pillars - the bits of the problem that are definite and which I will build off of.

Yes, starting with tests without market fit can also be fatal. But calling anything done without tests is just a slower poison. Before you airlift your brain to another unrelated problem you need to codify some of your assumptions. If you’re good at testing you can write them in a manner that makes it easy to delete them when requirements change. But that takes practice a lot of people don’t have because they avoid writing tests or they write the exact same kinds of tests for years at a time without every stretching their skills.

If you’re not writing tests you’re not writing good ones when you do. Testing is part of CI and the whole philosophy of CI is do the painful parts until you either grow callouses or get fed up and file off the scratchy bits. To avoid testing is to forget the face of your father.

Re: Throwing away 18 months of code and starting over

#63

Post by Jtsummers »

UltraSane wrote: post #20
oraphalous wrote: post #12

Earlier quoted context omitted.

[flagged]

Not having ANY tests means tons of manual testing is needed every time you modify code, which will rapidly consume more time than writing the tests would.

The manual tests also stop being run, or get reduced to such an extreme that any value from them is going to be low. Testing only happy paths and maybe release specific tests. This is shockingly (to outsiders, not to anyone who's ever been in the industry) common in aerospace and defense systems. There were some aircraft I would not fly on for a few years until I knew our updates had rolled out. Now I'm not connected to that work anymore so I'm back to "ignorance is bliss" mode and try not to think about it.

Re: Throwing away 18 months of code and starting over

#64

Post by Jtsummers »

hinkley wrote: post #62
oraphalous wrote: post #60

Earlier quoted context omitted.

I think maybe - this conversation is more about giving some more acknowledgement to the other side of this issue. It's not that I disagree with you essentially - or particularly with respect to your analysis of your specific examples. 100% in the cases you describe. Those sound like beneficial tests. Particularly because your example SPEAKS to the business case - users were using the help docs (I think you mean users…

There is supposedly a famous video series of Uncle Bob trying and failing to solve sudoku with TDD. He did not read any guides on solving it and tried from first principles instead, and bounced off of it. It’s clear to me that if you don’t know what you’re building, testing it first has rubber duck value that can easily be overshadowed by Sunk Cost. I always test my pillars - the bits of the problem that are definite…

Not Bob Martin, sudoku with TDD was Ron Jeffries.

https://news.ycombinator.com/item?id=3033446 - Linking to this old comment because it links to each of Ron's articles, a discussion about it, and Norvig's version.

Re: Throwing away 18 months of code and starting over

#65

Post by emil-lp »

oraphalous wrote: post #42
emil-lp wrote: post #34

Earlier quoted context omitted.

Forbidding tests is not a business decision, it's a software engineering decision, and it's a remarkably poor one at that.

Hard disagree. It's both. Choosing one way or the other comes with potential risks and rewards to the business and it's up to business leadership to choose what risks they want to take. Your job as an engineer - if you are not part of leadership is to explain those risks / rewards, and then let them make the call.

Okay, yes, that's a hard disagree.

I have an education and experience in software development. If a manager told me to make a product in an unsafe manner, I'd refuse, and if push came to shove, leave.

Leave, both because I wouldn't be able to defend my work as a professional, but also because I wouldn't work under someone who would want to dictate the manner in which I do what I do.

Re: Throwing away 18 months of code and starting over

#66

Post by qingcharles »

notorandit wrote: post #27

It's a big move. But I understand it. Sometimes your code is "just" a proof of concept, a way to test the idea. Very far from a decent product. That is the time you ditch the code, keep the ideas (both good and bad) and start over.

This. Depending on the project, especially if you're doing something really novel, you can end up going down dozens of dead-ends which, when removed, leave little scars all over the code base.

It can be so refreshing making that decision to open the old code on one screen and a fresh project on the other and do it right from the start.

Re: Throwing away 18 months of code and starting over

#68

Post by basket_horse »

emil-lp wrote: post #65
oraphalous wrote: post #42

Earlier quoted context omitted.

Hard disagree. It's both. Choosing one way or the other comes with potential risks and rewards to the business and it's up to business leadership to choose what risks they want to take. Your job as an engineer - if you are not part of leadership is to explain those risks / rewards, and then let them make the call.

Okay, yes, that's a hard disagree. I have an education and experience in software development. If a manager told me to make a product in an unsafe manner, I'd refuse, and if push came to shove, leave. Leave, both because I wouldn't be able to defend my work as a professional, but also because I wouldn't work under someone who would want to dictate the manner in which I do what I do.

This is missing the point. If you’re a 2 man team it’s much more important to have code that has a couple bugs in it but allows you to quickly find your product market fit. As opposed to perfect code with no bugs that is useless.

No one is disagreeing that tests are good in a vacuum / mature product. But if your focus is building a mvp, and you’re trading off the test time with other things, it’s not always worth it.

Screw “leadership” but consider for a second that you’re the leadership.

Re: Throwing away 18 months of code and starting over

#69

Post by iddan »

simonw wrote: post #36

"For the longest time, I would NOT allow people to write tests because I thought that culturally, we need to have a culture of shipping fast" Tests are how you ship fast. If you have good tests in place you can ship a new feature without fear that it will break some other feature that you haven't manually tested yet.

Worked with a CTO that had the same rule of thumb. I quickly proved strategic testing is net positive for the business

Re: Throwing away 18 months of code and starting over

#70

Post by oraphalous »

hinkley wrote: post #62
oraphalous wrote: post #60

Earlier quoted context omitted.

I think maybe - this conversation is more about giving some more acknowledgement to the other side of this issue. It's not that I disagree with you essentially - or particularly with respect to your analysis of your specific examples. 100% in the cases you describe. Those sound like beneficial tests. Particularly because your example SPEAKS to the business case - users were using the help docs (I think you mean users…

There is supposedly a famous video series of Uncle Bob trying and failing to solve sudoku with TDD. He did not read any guides on solving it and tried from first principles instead, and bounced off of it. It’s clear to me that if you don’t know what you’re building, testing it first has rubber duck value that can easily be overshadowed by Sunk Cost. I always test my pillars - the bits of the problem that are definite…

> Yes, starting with tests without market fit can also be fatal. But calling anything done without tests is just a slower poison.

I think we are pretty close to agreement here. I'd be interested in what you have experienced in the realm of front-end testing though - whether you think things are just as cut and dried in that realm (that's another discussion though).

And I'll also accept the point about skill in test writing that improves the cost-benefit analysis. I'll also cop to not having that kind of practiced ability at testing to the level I would personally like. But it's chicken / egg. A lot of folks get their start at scrappy start ups that can't attract the best talent. And just can't afford to let their devs invest in their skills in this way. Hell - even established companies just grind their devs without letting them learn the shit they need to learn.

I feel a victim of this to some degree - and am combating it with time off work which I can afford at the moment. One of the things I'm working on is just understanding testing better - y'know, so I can in the future write a SKILL.md file that tells Claude what sort of tests it should write. lol...

Post reply on HN