4 ms·

The 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 bo

The 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 ago
Agreed, 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

rockemsockem 2y ago

Agreed, 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