|
|
|
|
|
by c0mpute
4772 days ago
|
|
The problem with this approach, while great for you, the developer it is a nightmare for the future team. I am now working at a startup where the early devs have left. They did precisely what was needed at that point - build quickly, ensure it works for the 3/4 customers we had back then and document it as well.
Fast forward a year later, that same code is no longer extensible for many clients. Its rigid and tightly coupled and rewriting some parts means, we have to pretty much rewrite a whole lot more than we bargained for. We will have to burn through a lot of cash to just build a whole new product based on some of the scalability and maintenance learning we now have from a year of learning and growing to client# 100. The point is, there is always going to be "this is the right thing right now, its what our customers want" and then something else for the future. I have seen that people who have worked for a while and in many startups do the smart thing (as expected) and while follow "build for now" they also do the sensible thing of investing for the future (from experience). |
|