One of the biggest plagues of web development is being in too much of a hurry. Yes, there are times where nothing is more important than moving fast, but we often take that as the default, when it is actually the exception.
Projects that move steadily towards greatness are the ones that last. It's hard to justify that statement with certainty, but I believe we think that old technologies are bad and that we always need to be moving on to the new stuff, but this is mostly true for projects that were built to be flimsy in the first place. So this line of thinking is kind of a self-fulfilling prophecy.
If this generic graph measure's the potential value a project can deliver over time, it would be silly to optimize our time and effort towards the small area under the curve, instead of the big one. Methodical craftsmanship wins out if we can take this mindset.
Being meticulous early on so that you can achieve hyper speed when you need it is the way to optimize for longterm value. There will be a lot of straight aways where you can move really really fast because you've set yourself up to do so early on.
Think in the long term by focusing on the details early on in a project. Don't try to predict the long term future too much, but trust that craftsmanship now will pay off then. Set expectations with people who don't want to think long term. Take long walks where you think through the future, and then put it out of your mind and craft something beautiful now. And have fun.
Top comments (5)
Yeah. Shortcuts are often necessary but they need to be the right ones. It's so easy to paint yourself into the corner. A big problem in the real world is that companies are heavily incentivized to think short term. Big companies and small companies alike. It takes a hell of a lot of leadership to convince people that longterm thinking is the right move.
Amazon is probably the best example of an organization that has been consistently given the leash to think longterm because they've willed the market to come along with them on that ride.
This post is a train of thought. I see these conclusions as sort of self-evident, but I'm not sure I'll ever be able to articulate proof that any of these ideas are right. Sorry for not discovering the silver bullet.
It reads as if you're reflecting on events. Curious to know what the events were. My best guess is they're
dev.torelated.Thanks for sharing :)
I am not sure I am getting it. For example where does that curve come from ?
I would agree that the value of a software would be somewhat linear to the numbers of users / money they would agree to put on it. And I would agree that to get more users, you likely need "greater" software... Faster, more scalable, with more features yet manageable and usable. Because not all users have the same needs.
On the opposite, the cost of software is exponential to its size. The bigger, the older, the more feature it has, the more it cost to just maintain it and to add new features. Up to a point when not so profound changes take billions of investment. At some point, it is not worth it as the cost is bigger than the expected benefit.
Even if the design is the best in the world, there no way arround that. Agree that we all try to improve our design, but the best ones are the one that actually allow for low coupled independant part to be replaced at any time without impact on the overall system. More or less the best designs, are the one that make capilizing long term of a given code uncessary.
Most API/libraries that are 10 years or older are not used anymore. Actually, out of all websites/app software. Only a few are kept. Not necessarilly the best coded, but the ones that survived because their user base is still there.
Software is really an area where winner take it all. Most startup/companies also completely shift their business model and use cases over time. Simply to adapt, to survive. How would have helped netflix recently if they made their DVD exchange system 10 time better now they stream video over the internet? Their business and their software requirement are completely different than when they started.
You have to be able to fail fast, to iterate and evolve. For that using on the shelf architectures/lib/components and getting things done that matter to your client/user base is more important than a clean design.
The day you found your niche, where to grows and how to do it, there always time to consolidate. It isn't like the software effort you put on the first few years of work when you were small and trying to solve a different problem would be that usefull anymore.
But I agree that in term of high level abstractions. Things maybe beyond a single component/software but more overal architecture can help tremendously.
Another comment speak of amazon. They indistrialized their SOA architecture. So their bottleneck might very well be too chatty app at time or evolution of exchange format, but they can easily had a new component, replace a old one with a different implementation and so on.
Using the cloud concept and scalable architecture, including not having a single centralized database, they can scale infinitely.
And they actually don't care what OS/language/lib whatever a component use. If the team just replaced all the code or not. Because that system is modular it can evolve independantly, part by part... Except again when they need to change/update the exchange format. This is costly.
I'm wondering whether this speaks to the great quality in the open-source community, where there's much less, if any, time pressure.
I'm working on a GitHub project right now, where I always feel that I have the time to do it right, so I won't later have to do it over.