Whatever works(sahillavingia.com)
sahillavingia.com
Whatever works
http://sahillavingia.com/blog/whatever-works/
24 comments
The point of the debt analogy is to communicate that it's something long-term undesirable, although it can be a short-term expedient. Where the analogy falls short is that real debt almost always has to be repaid. In a startup searching for product-market fit, the opposite true re. technical debt.
Joel Spolsky made a similar point in one of the stack overflow podcasts.
He and Jeff were talking about twitter's downtime and Joel said something along the lines of "and look at how all those other startups destroyed twitter by having more up time."
The point being is that twitter just went ahead and shipped. They were able to fix their software issues after they found out what their product actually was.
He and Jeff were talking about twitter's downtime and Joel said something along the lines of "and look at how all those other startups destroyed twitter by having more up time."
The point being is that twitter just went ahead and shipped. They were able to fix their software issues after they found out what their product actually was.
Perhaps people also have low expectations for software.
> Perhaps people also have low expectations for software.
Maybe, but I don't think that has anything to do with the point that people could have easily migrated to other clones but stayed with twitter as it was the best platform, performance woes aside.
Maybe, but I don't think that has anything to do with the point that people could have easily migrated to other clones but stayed with twitter as it was the best platform, performance woes aside.
i would like to think of twitter as the exception, with all the press, investor hype and celebrities it was hard for it to fail. I highly doubt that many startups could handle that kind of downtime and still be successful
There is an important side effect of this mentality: you are stuck with a weak foundation. Not only technically but also in front of the eyes of the consumers.
When you ship a product users build expectations about it. They use in different ways that the ones you might have expected. If during further development you understand that a feature is not desirable anymore (e.g for technical problems with some other super awesome feature) pulling support may backfire.
This was evident in each Facebook redesign, or in the new version of Final Cut Pro.
Therefore, I think that there is definitely a sweet spot and that this spot isn't "ship it as soon as it works".
When you ship a product users build expectations about it. They use in different ways that the ones you might have expected. If during further development you understand that a feature is not desirable anymore (e.g for technical problems with some other super awesome feature) pulling support may backfire.
This was evident in each Facebook redesign, or in the new version of Final Cut Pro.
Therefore, I think that there is definitely a sweet spot and that this spot isn't "ship it as soon as it works".
It's a pretty common concept. You can't be a successful entrepreneur or a manager without a "well, as long as it works" mentality.
"Jugaad": http://blogs.hbr.org/cs/2010/01/jugaad_a_new_growth_formula_...
"Jugaad": http://blogs.hbr.org/cs/2010/01/jugaad_a_new_growth_formula_...
I really do not agree with that, now that can work with small websites you don't care about and just not going to do maintenance.
but in my experience, the technical debt will be a big problem later on, if not a total deal breaker. This is a problem found a lot in html integration, and jQuery new comer that push one millions of events in the dom.ready
Unmaintainable mess = hours and hours of lost work
I find that the easiest and cleanest solution is generally the better, I always try to not over engineer my code.
but in my experience, the technical debt will be a big problem later on, if not a total deal breaker. This is a problem found a lot in html integration, and jQuery new comer that push one millions of events in the dom.ready
Unmaintainable mess = hours and hours of lost work
I find that the easiest and cleanest solution is generally the better, I always try to not over engineer my code.
Sounds like someone who doesn't have to maintain his own code.
I had the very same thought.
This mentality is fine if you don't want to (or have to) maintain and support anything—and from looking around the author's site, it appears he makes dozens of small things and then leaves them to rot.
This mentality is fine if you don't want to (or have to) maintain and support anything—and from looking around the author's site, it appears he makes dozens of small things and then leaves them to rot.
Making dozens of quick things to try them out (and then abandoning them) isn't such a bad strategy when searching for a good business idea. Obsessing over the backend of an mvp might be a net negative.
And if he had spent time obsessing over internal code details would the project rot less?
Things change fast in software. It's one thing if you're building the backend system behind a billion dollar bank. Obviously that's not what the author is talking about.
If you're trying to make the next Angry Birds, or Facebook, or Google, you need to get something out there now, the MVP, and iterate.
Things change fast in software. It's one thing if you're building the backend system behind a billion dollar bank. Obviously that's not what the author is talking about.
If you're trying to make the next Angry Birds, or Facebook, or Google, you need to get something out there now, the MVP, and iterate.
I find myself struggling with this constantly as I develop iOS apps. There's something about the programmer's brain that gets obsessed with the details, and doing it the "right way", and tweaking for completely insignificant performance gains, and just loves researching all the minutia.
You need to Get It Done. Especially if you're dealing with consumer software, you need to get something infront of the customer, because in 6 months everything may have changed!
If you have the luxury of working on corporate software where you have loose deadlines, open budget, and no competition, well go ahead and comment all your code and research all your best practices. It might even be worthwhile, because there's a much better chance that code will still be around in 8 years. If you're a startup, forget it, your product will likely be defunct in 6 months.
You need to Get It Done. Especially if you're dealing with consumer software, you need to get something infront of the customer, because in 6 months everything may have changed!
If you have the luxury of working on corporate software where you have loose deadlines, open budget, and no competition, well go ahead and comment all your code and research all your best practices. It might even be worthwhile, because there's a much better chance that code will still be around in 8 years. If you're a startup, forget it, your product will likely be defunct in 6 months.
The only point to rewriting is to extend the project.
You can't always predict if new features will be wanted. So unless you want to have to wait on a rewrite for each new feature you will need a rewrite.
Rewriting all your code because you might need to extend it is a bigger waste of your time than spending that 20% longer to make all your code extendible.
If you don't want to rewrite for the new feature then you contribute to the spaghetti.
Due to your bad code it'll take increasingly long to add features and you will eventually spend longer implementing the whole system (with extra features) than implementing a nice version first.
You can't always predict if new features will be wanted. So unless you want to have to wait on a rewrite for each new feature you will need a rewrite.
Rewriting all your code because you might need to extend it is a bigger waste of your time than spending that 20% longer to make all your code extendible.
If you don't want to rewrite for the new feature then you contribute to the spaghetti.
Due to your bad code it'll take increasingly long to add features and you will eventually spend longer implementing the whole system (with extra features) than implementing a nice version first.
As C2 puts it, "Do the simplest thing that could possibly work."
http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.htm...
http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.htm...
For a sufficient definition of "works", whatever indeed works.
In business, you sometimes have to release code that isn't perfect. However, I've seen too many apps that were hacked together to get them out the door. After customers are using it, you really almost never get a chance to rewrite it from scratch and the end result is a system that becomes a monster to maintain.
But it works. And users will never know the difference.
Sure they will, when your app starts to crash, or become unreasonably slow due to something hacked together without a second thought as to how well it would work.
Sure they will, when your app starts to crash, or become unreasonably slow due to something hacked together without a second thought as to how well it would work.
The only software I have used that doesn't crash or hang occasionally is the bare linux command line and bash. Everything else has occasional or worse problems. I'm beginning to think software is another one of those things that has no "Good", just "Bad" and "Worse". (Linux may not crash or hang, but it is a royal pain to configure on/for some hardware.)
Like how dataapp.com is not responding right now, you mean? I think he just disproved his point...
From the article: In later versions, I had to rewrite the entire database solution I had built (think one large array of objects for the entire app… yeah, seriously, but it worked!)
The rewritten version doesn't prove anything about the initial hack.
The rewritten version doesn't prove anything about the initial hack.
It is occurring to me now that mastery of software development probably involves knowing how and when to invoke "whatever works" wisely.
Indeed, I am coming to this conclusion myself. Most of us can write code. Most of us can do capital-A Architecture by reading blogs. The thing that separates programmers that I want to work with are those that who maximize the ratio of benefit to work.
It's not about the code, it's about economics in the broad sense -- understanding opportunity cost, understanding what "benefit" looks like, understanding your team, and making informed trade-offs.
No one thinks duct-tape code is "good" as an art form, but it might be the right decision for a given point in time.
It's not about the code, it's about economics in the broad sense -- understanding opportunity cost, understanding what "benefit" looks like, understanding your team, and making informed trade-offs.
No one thinks duct-tape code is "good" as an art form, but it might be the right decision for a given point in time.
Ward Cunningham (http://c2.com/doc/oopsla92.html)
See also, Technical Debt (http://en.wikipedia.org/wiki/Technical_debt).