5 ms·

> However, startups don't fail because the codebase is ugly, or convoluted, or not following best practices. Startups do fail due to a failure to execute. Best

> However, startups don't fail because the codebase is ugly, or convoluted, or not following best practices. Startups do fail due to a failure to execute. Best practices aren't always about aesthetics. Ignore them too much and you end up with write-only code. You can compensate in various ways, such as designing the code so that it's possible to throw away the ugly parts later. You are correct that good senior engineers are apt at striking this balance. I do not agree that the typical senior engineer is competent at this.

PragmaticPulp 6y ago
Right, which is why my sentence right before what you quoted emphasized that the product must work properly and not be full of bugs. I considered combining them into one run-on sentence so people wouldn’t be tempted to take it out of context. Obviously, the product must work, must not be buggy, and must be maintainable enough to move forward. However, there’s nothing wrong with what you call write-only code in certain circumstances, especially at a startup. I’d much rather have some backed together, single-use code that lets us prove demand before investing resources in a proper rewrite. The project goals will likely change after first contact with the customer anyway. One of the biggest time wasters I’ve seen at startups is engineers who lose track of the goal and instead start writing reusable frameworks, or over-generalized code, or separating architecture into modules so they can open-source part of it on GitHub. Startups are trying to prove a business model as fast as possible. Once you prove demand, you scale it with the proper code backing it up.
JamesBarney 6y ago
Curious when you've worked with write only code what was the language? I've been on like 30 different projects over the last 10 years and never encountered write only c#. But I have come pretty close to encountering write only javascript. It seemed like static typing, "find all references" and the limited use of reflection style coding made the difference between bad code being annoying and completely unworkable.
- umut 6y ago
  I second this rather strongly.. The harder it gets to "stop" and clean-up shit, the quicker it gets to just lose it.. Especially relevant in environments where the authors of the write-only codebase are not around anymore. Somehow it is hard to blame/hate someone you go out with for lunch or beers. What really worked great for my teams in the past is to game the transition so that the team as a whole sees it as an internalized mission, usually much stronger than that of the company. Then killing X lines of code from the old mess and beautifying the codebase becomes a shared and extremely satisfying exercise
- humanrebar 6y ago
  I've seen write-only Java where the design was fragmented over so many classes that nobody could really make a meaningful design change anymore. Classes with dozens of methods, gross violations of SOLID principles, etc. It seems entirely possible to do the same in C#. That being said, languages in that space seem generally less prone to write-only code, so I'd agree that language choice has a big impact. Especially when an entirely novel language or framework enters the picture.

PragmaticPulp 6y ago

Right, which is why my sentence right before what you quoted emphasized that the product must work properly and not be full of bugs. I considered combining them into one run-on sentence so people wouldn’t be tempted to take it out of context. Obviously, the product must work, must not be buggy, and must be maintainable enough to move forward. However, there’s nothing wrong with what you call write-only code in certain circumstances, especially at a startup. I’d much rather have some backed together, single-use code that lets us prove demand before investing resources in a proper rewrite. The project goals will likely change after first contact with the customer anyway. One of the biggest time wasters I’ve seen at startups is engineers who lose track of the goal and instead start writing reusable frameworks, or over-generalized code, or separating architecture into modules so they can open-source part of it on GitHub. Startups are trying to prove a business model as fast as possible. Once you prove demand, you scale it with the proper code backing it up.

JamesBarney 6y ago

Curious when you've worked with write only code what was the language? I've been on like 30 different projects over the last 10 years and never encountered write only c#. But I have come pretty close to encountering write only javascript. It seemed like static typing, "find all references" and the limited use of reflection style coding made the difference between bad code being annoying and completely unworkable.

umut 6y ago
I second this rather strongly.. The harder it gets to "stop" and clean-up shit, the quicker it gets to just lose it.. Especially relevant in environments where the authors of the write-only codebase are not around anymore. Somehow it is hard to blame/hate someone you go out with for lunch or beers. What really worked great for my teams in the past is to game the transition so that the team as a whole sees it as an internalized mission, usually much stronger than that of the company. Then killing X lines of code from the old mess and beautifying the codebase becomes a shared and extremely satisfying exercise
humanrebar 6y ago
I've seen write-only Java where the design was fragmented over so many classes that nobody could really make a meaningful design change anymore. Classes with dozens of methods, gross violations of SOLID principles, etc. It seems entirely possible to do the same in C#. That being said, languages in that space seem generally less prone to write-only code, so I'd agree that language choice has a big impact. Especially when an entirely novel language or framework enters the picture.