4 ms·
This article buries the lede with a bunch of horrendous strawmen. The actual thesis is that software craftsmanship should be applied in the same way at all sta
by dasil003 2y ago
This article buries the lede with a bunch of horrendous strawmen. The actual thesis is that software craftsmanship should be applied in the same way at all stages of a company. This is a very dangerous line of thinking that has killed many a startup staffed by experienced who engineers who are working in large scale systems and teams. I've seen it many times, and TBH it's not just an engineering problem, it's that people who have only worked in large companies don't have a real sense of what is truly essential, and so a huge percentage of their practices are effectively cargo culted over without any real reflection.
In the case of engineering, you need to apply a lot of judgement based on the situation that the company is in—how much runway, how much traction, actual product goals, etc. You must keep things as simple as possible at all times to optimize for future optionality as you search for product-market fit. All code is a liability, and you must fight tooth and nail against any individual who is getting ahead of their skis in terms of losing focus on the next thing needed to prevent the company from dying. The absolute worst thing you can do is bring some journeyman engineer and don't give them enough scope and ownership to satisfy their brain capacity or you'll end up with ridiculously over-engineered systems that impose a huge velocity tax for what needs to be a very lean and agile phase. I say this disclaimer first because 99% of people in tech trying to do a startup will fail by trying to do too much too soon, and have no intuitive sense of how narrow the tightrope from 0 to 1 success really is.
Of course that doesn't mean you shouldn't focus on code and system quality. Absolutely you should have tests, but you should apply serious judgement onto the nature of the tests in light of your best predictions about the future. You should think about what code is foundational, and what decisions may be one way doors, but not obsess over leaf nodes and experiments that are just as likely to be abandoned or scrapped as they are to be built upon. Making these calls is tough—no one can predict the future—but long tenures in fast growing code bases helps. Seeing the impact of ones decisions 2, 5, 10 years down the line is eye opening, experience is useful here as long as one still thinks from first principles and doesn't just rely on rote practices because they are comfortable.
- rockemsockem 2y agoI think you are actually agreeing with the main thesis of the article, which I agree buries the lede and obfuscates it with overly focusing on TDD in particular. You're just adding the, accurate, caveat that most people's opinions on how to build good software are wrong. I think that it's true that at large companies there can be an obsession with over-design and over-engineering "for scale", but I actually think that's wrong to do at large companies too, you're just less likely to pay the ultimate price for wasting time on it.
- dasil003 2y agoThe overall article is ambiguous enough that yes, it can be interpreted to be in alignment with my values. But also based on my quarter century experience in both startups and Fortune 500s and the transition from the former to the latter, I would say for every engineer shooting from the hip and creating an unmaintainable mess there is an equal number who will read it as a justification for over-engineering. Also, though of course most startups fail, I would say the latter archetype fails at a higher rate because they are focused on the wrong things. The crux is really is the nuance of this statement: "The disciplines that lead to successful software are always valid". This is tautological, everyone reads and sees what they want to see. But if we take the examples he gives, that's where judgement comes in. Double-entry bookkeeping, yes, that's pretty universal. TDD? That really depends on what you are doing and what value you get out of it. Not only do specific disciplines and practices vary based on company stage, they also vary based on the product and the goals of the business. Anyone who doesn't understand this is fucked if they try to do a startup.
- rockemsockem 2y agoAgreed, but I would say it isn't necessarily tautological. I think there are lots of people out there who think that if you want to develop software faster you cut corners on things like testing (to be clear I'm not endorsing TDD, just saying having a reasonable number of tests beats the hell out of none), choosing a dynamically typed language vs a statically typed one, and just generally throwing code over the fence for the sake of moving fast. I think it's true that you will in fact move faster over time (not even a very long time, just like a few months) if you stick to whatever good principles you would have stuck to if you didn't have the time pressure of shipping while at a startup. My read was that this was intentionally vague since it's basically trying to say to the reader that whatever you think is a good idea too do while developing software at a non-startup is also a good idea to do at a startup. If the reader has bad ideas about developing software then clearly there's no helping them :P
- yarekt 2y agoExactly. All those things that are critical in a startup are really good way to accelerate possibly stagnant development. However, short-sightedness and ignoring tech debt kills startups too