I ran into some serious struggles when we got far enough into accepting most of the tenets of XP as standard practice that most jobs didn’t even debate half of them and then landed at places that still thought they were stupid. I’d taken for granted I wasn’t going to have to fight those fights and forgotten how to debate them. Because I Said So is not a great look.
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.
"bugs were appearing everywhere out of the blue. The codebase was a huge mess of nulls, undefined behaviour, bad error handling. It was so bad that we actually lost a client over this."
Especially wild considering their product is literally an automated bug finder lol.
> 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.
Next is such a dumpster fire. So much wasted effort due to the Node ecosystem never developing a universal batteries included framework like Rails or Django.
Which in turn were only invented because millennials would not be caught dead writing Java and JSP. We had all this shit figured out by the late nineties and 90% of what is accomplished on the web today was entirely possible and well integrated in Java app servers.
This whole business is a fashion industry.
I'm for one grateful for LLMs because for the first time in around 30 years there is actually genuine novelty to explore in software engineering. Ruby and nodejs weren't it.
MVC really changed web dev for the better, and Django/Rails trail-blazed it. It's one of the few paradigms I've seen in my career that was an unequivocal win for us.
We were already doing MVC in products like the one sold by Altitude Software in Portugal, in a Tcl based platform that was inspired on Vignette and AOLServer.
The authors of said product eventually went on to create OutSystems, one of the very few RAD products to do Delphi/VB like application servers with graphical tooling.
It was no need for Django/Rails trail-blaze anything other than not everyone has Silicon Valey visibilty to push their ideas.
Indeed, as someone confortably on Java/.NET ecosystem, I only put up with stuff like Next.js, because it has become a required skill in the headless SaaS products space.
Thanks to Vercel partnerships, many of those SaaS vendors only support Next.js as extension/integration technology on their SDKs.
Unfortunely parterships made it almost unavoidable in some industry segments, I wonder what all those SaaS vendors will do if something goes wrong with Vercel, or when Next.js becomes unmanageable after yet another rewrite.
Maybe they will rewrite everything with AI by then. /s
Two different stages of the project, not necessarily contradictory. I'm not saying this is great, but tests make a whole lot more sense when you know what you're building.
Yes. TFA author could have gone into it with this mindset and treated the initial work as a prototype with the idea of throwing it away and would have been happier about it.
> but tests make a whole lot more sense when you know what you're building.
It's very true. This is a "gotcha" a lot of anti-TDDers always bring up, and yet some talk about "prototyping == good" without ever making the connection that you can do both.
Two different extremes of dumbassery. If you can't program without the simplest dogma guiding you then programming isn't for you. If you don't even know what you're building why are you selling it as a product?! What are you doing in those 18 months that you don't understand anything about the thing you are building.
It should be common sense to add common sense tests to critical components. Now they are doing TDD THEY STILL DON'T KNOW THE CRITICAL COMPONENTS. Nothing changed. They lack systems thinking.
Tests are most useful for regression detection, so it's a good instinct to not add them when you're primarily exploring. Once you've decided to switch to exploitation, though, regression will hurt. I think it's just a classic 0 to 0.1 not being the same thing as 0.1 to 1.
It's not really hinted at in the article, which doesn't actually mention whether the rewrite was a net gain - I presume it was or they wouldn't have written the article, and the lead-in picture paints a rosy picture, but the tone at the end suggests he's not happy with how things turned out.
But one thing that used to be a common design anti-pattern was the "version 2 problem". I think I first heard about it when Netscape were talking about how NN2 was a disaster, and they were finally happy with NN3 or NN4.
Often version 1 is a hastily thrown together mess of stuff, but it works and people like it. But there's lots of bad design decisions and you reach a limit with how far you can continue pushing that bad design before it gets too brittle to change. So you start on version 2, a complete rewrite to fix all the problems and you end up with something that's "technically perfect" but so overengineered, it's slow and everybody hates it, plus there are probably lots of workflow hoops to jump through to get things approved that you end up not making any progress, and possibly version 2 kills the product and/or the company.
The idea is that the "version 3" is a pragmatic compromise - the worse design problems from version 1 are gone, but you forego all the unnecessary stuff that you added in version 2, and finally have a product that customers like again (assuming you can convince them to come back and try v3 out) and you can build into future versions.
To a large degree I think this "version 2 problem" was a by product of waterfall design, it's certainly been less common since agile development became popular in the early 2000s and tooling made large scale refactoring easier, but even so I remember working somewhere with a v1 that the customers were using and a v2 that was a 3-year rewrite going on in parallel. None of the developers wanted to work on v1 even though that's what brought in the revenue, and v2 didn't have any of the benefit of the bug fixes accumulated over the years to fix very specific issues that were never captured in any of the scope documents.
"The general tendency is to over-design the second system,
using all the ideas and frills that were cautiously sidetracked on
the first one. The result, as Ovid says, is a "big pile."
That and Brooks’ underrated “The Design of Design” are notable for having an almost impossible density of quotable aphorisms on every page. They’re all so relevant today that it’s hard to believe that he’s talking about problems he faced half a century ago.
Never heard of "The Design of Design" but I bought it off this comment chain.
I think our industry would do a lot to take a moment and breath to understand what we have collectively done since inception. Wonder often if we will look at the highly corporatized influence our industry has had during our time as the dark ages 1000s of years into the future. The idea that private enterprise should shape the direction of our industry is deeply problematic, there needs to be public option and I doubt many devs would disagree.
This has been my experience exactly. V1 was custom built for a single client and they loved it. As we tried to expand to multiple clients the v1 was too narrowly scoped (both in UX and code architecture) so we did a full rewrite attempting to generalize the app across more workflows. V2 definitely expanded our client pool, but all our large v1 customers absolutely hated it.
We never did a full v3 rewrite, but it took about 4 years and many v3 redesigns of various features to get our legacy customers on board.
I definitely encountered this second-system effect recently. I have an app that works well because it was written to target a specific use case. User (and I) wanted some additional features, but the original architecture just couldn't handle these new features, so I had to do a rewrite from the ground up.
As I rewrote it, I started pulling in more "nice to haves" or else opening up the design for the potential to support more and more future features. I eventually got to a point where it became unwieldy as it had too many open-ended architectural decisions and a lot of bloat.
I ended up scrapping this v2 before releasing it and worked on a v3 but with a more focused architecture, having some things open-ended but choosing not to pursue them yet as I knew that would just introduce unneeded bloat.
I was quite aware of the second-system effect when doing all this, but I still succumbed to it. Thankfully, the v3 rewrite didn't take as long since I was able to incorporate a lot of the v2 design decisions but scaled some of them back.
My adaptation of the Version 2 Problem is “any idiot can ship version 1 of a product, but it takes skill to ship version 2”.
Usually levied at people who are so hyper focused on shipping a so-called MVP that is really demoware that they are driving us at a brick wall and commenting the entire way about what good time we are making.
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.
sorry, still don't get no tests as an excuse to go faster. obviously ymmv, but you will need to test your implementation somehow, and manual testing usually takes more time than running your automated tests. no need to over test, but definitely tests doesn't mean it will slow you down, unless you don't know how to test, which in that case, that's totally up to you.
I think the more specific description would be that "not writing tests allows shipping fast today, writing tests allows shipping fast tomorrow and afterwards".
It wasn't too long ago that I wrote tests for something that was shipped years ago without any automated tests. Figured it was easier doing that than hoping we won't break it.
If you are going to test what you develop might as well write any tests you do formally right away. It is unlikely you get it fully ready in one go, so you need to anyway run same tests again when you iterate it developing it today.
And that is the minimum level to aim at. If you can automate anything you do to test it right now you should.
The rewrite version of this that has gone best for me is to do it as a strangler, not a reset. Pick one ugly workflow, lock in current behavior with characterization tests, rebuild that slice behind a flag, repeat. You still get to fix the architecture, but you do not throw away years of weird production knowledge.
I can't imagine working as a developer at a place where manager/founder "does NOT allow" tests to be written. This, combined with four pivots mentioned in the article seems like they are just riding the hype and trying to brute-force a product without having any basics or PMF.
https://news.ycombinator.com/item?id=47317568 - A submission by this person's company where they say they'll refund you if a bug makes it past their system. Given how buggy their own system apparently is (to the point they're scrapping all the code), perhaps it's not such a smart offer on their part.
Who are you people? 4 pivots and still going with "no tests" -> "tests first" rewrites. I mean, people say tech jobs are on down trend, projects are drying. And then there is this. I just can't make sense.
maplant | a day ago
kace91 | a day ago
I feel like we keep having to reestablish known facts every two years in this field.
hinkley | a day ago
paulhebert | 23 hours ago
andrewstuart | a day ago
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.
randlet | a day ago
Especially wild considering their product is literally an automated bug finder lol.
pavel_lishin | 2 hours ago
monsieurbanana | a day ago
stephantul | 23 hours ago
ordu | 22 hours ago
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.
ramesh31 | a day ago
abraxas | a day ago
This whole business is a fashion industry.
I'm for one grateful for LLMs because for the first time in around 30 years there is actually genuine novelty to explore in software engineering. Ruby and nodejs weren't it.
sgarman | a day ago
steve_adams_86 | a day ago
mattmanser | 23 hours ago
MVC really changed web dev for the better, and Django/Rails trail-blazed it. It's one of the few paradigms I've seen in my career that was an unequivocal win for us.
pjmlp | 10 hours ago
The authors of said product eventually went on to create OutSystems, one of the very few RAD products to do Delphi/VB like application servers with graphical tooling.
It was no need for Django/Rails trail-blaze anything other than not everyone has Silicon Valey visibilty to push their ideas.
pjmlp | 9 hours ago
Thanks to Vercel partnerships, many of those SaaS vendors only support Next.js as extension/integration technology on their SDKs.
pjmlp | 9 hours ago
Maybe they will rewrite everything with AI by then. /s
fabiensanglard | a day ago
> I would NOT allow people to write tests
> now [...] we started with tests from the ground up
Trufa | a day ago
sodapopcan | a day ago
> but tests make a whole lot more sense when you know what you're building.
It's very true. This is a "gotcha" a lot of anti-TDDers always bring up, and yet some talk about "prototyping == good" without ever making the connection that you can do both.
wagwang | a day ago
casey2 | 9 hours ago
It should be common sense to add common sense tests to critical components. Now they are doing TDD THEY STILL DON'T KNOW THE CRITICAL COMPONENTS. Nothing changed. They lack systems thinking.
My guess is that both are just vibecoded slop.
renewiltord | a day ago
ralferoo | a day ago
But one thing that used to be a common design anti-pattern was the "version 2 problem". I think I first heard about it when Netscape were talking about how NN2 was a disaster, and they were finally happy with NN3 or NN4.
Often version 1 is a hastily thrown together mess of stuff, but it works and people like it. But there's lots of bad design decisions and you reach a limit with how far you can continue pushing that bad design before it gets too brittle to change. So you start on version 2, a complete rewrite to fix all the problems and you end up with something that's "technically perfect" but so overengineered, it's slow and everybody hates it, plus there are probably lots of workflow hoops to jump through to get things approved that you end up not making any progress, and possibly version 2 kills the product and/or the company.
The idea is that the "version 3" is a pragmatic compromise - the worse design problems from version 1 are gone, but you forego all the unnecessary stuff that you added in version 2, and finally have a product that customers like again (assuming you can convince them to come back and try v3 out) and you can build into future versions.
To a large degree I think this "version 2 problem" was a by product of waterfall design, it's certainly been less common since agile development became popular in the early 2000s and tooling made large scale refactoring easier, but even so I remember working somewhere with a v1 that the customers were using and a v2 that was a 3-year rewrite going on in parallel. None of the developers wanted to work on v1 even though that's what brought in the revenue, and v2 didn't have any of the benefit of the bug fixes accumulated over the years to fix very specific issues that were never captured in any of the scope documents.
pjmorris | a day ago
- Fred Brooks, 'The Mythical Man Month' (1975)
ralferoo | a day ago
didgeoridoo | 23 hours ago
shimman | 23 hours ago
I think our industry would do a lot to take a moment and breath to understand what we have collectively done since inception. Wonder often if we will look at the highly corporatized influence our industry has had during our time as the dark ages 1000s of years into the future. The idea that private enterprise should shape the direction of our industry is deeply problematic, there needs to be public option and I doubt many devs would disagree.
basket_horse | a day ago
We never did a full v3 rewrite, but it took about 4 years and many v3 redesigns of various features to get our legacy customers on board.
allenu | a day ago
As I rewrote it, I started pulling in more "nice to haves" or else opening up the design for the potential to support more and more future features. I eventually got to a point where it became unwieldy as it had too many open-ended architectural decisions and a lot of bloat.
I ended up scrapping this v2 before releasing it and worked on a v3 but with a more focused architecture, having some things open-ended but choosing not to pursue them yet as I knew that would just introduce unneeded bloat.
I was quite aware of the second-system effect when doing all this, but I still succumbed to it. Thankfully, the v3 rewrite didn't take as long since I was able to incorporate a lot of the v2 design decisions but scaled some of them back.
hinkley | a day ago
Usually levied at people who are so hyper focused on shipping a so-called MVP that is really demoware that they are driving us at a brick wall and commenting the entire way about what good time we are making.
heliumtera | a day ago
4rtem | a day ago
notorandit | a day ago
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.
qingcharles | 22 hours ago
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.
notorandit | 6 hours ago
dagi3d | a day ago
simonw | a day ago
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.
Hamuko | 23 hours ago
It wasn't too long ago that I wrote tests for something that was shipped years ago without any automated tests. Figured it was easier doing that than hoping we won't break it.
simonw | 23 hours ago
Your tests pay for themselves the moment you want to ship a second feature without fear of breaking the first.
Ekaros | 9 hours ago
And that is the minimum level to aim at. If you can automate anything you do to test it right now you should.
ephou7 | 23 hours ago
pastescreenshot | 23 hours ago
iddan | 21 hours ago
elAhmo | 23 hours ago
nineteen999 | 21 hours ago
Jtsummers | 21 hours ago
aaronrobinson | 10 hours ago
tecoholic | 7 hours ago
UncleEntity | 3 hours ago
mpalmer | 6 hours ago