http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660@Joseph, "reget" -> "regret" :( That it would, that it would. The scary thing is, I'm having a non-trivial number of GMs ask me what the "regret cost" is. http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment22http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment22Wed, 03 Feb 2010 12:35:21 GMT>>Actually, data centers on the internet tend to be cheaper (GoGrid, EC2). Cloud computing is only cheaper if you need entry level servers with slow and low bandwidth. I was talking about if your software needs to run on your *own* data centre where you have your POP connected directly to tier 1 servers on the internet. In this case you need to buy and maintain your own routers, switches, backup, redundancy, etc. Needing 2 or 3 * extra servers because your software is inefficient adds up to a significant cost. http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment21http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment21Wed, 03 Feb 2010 09:46:42 GMTDemis, Actually, data centers on the internet tend to be cheaper (GoGrid, EC2). And handling thousands of users is EASY, you don't think about perf at that level http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment20http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment20Wed, 03 Feb 2010 07:22:47 GMTPeter - your point would have been better made if you'd spelt 'regret' correctly in the link. reget cost I was thinking "cost of stale cache reads" or something like that. http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment19http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment19Wed, 03 Feb 2010 06:32:43 GMTAhhh... the old warhorse, the [reget cost](http://peter.evans-greenwood.com/2009/11/26/the-price-of-regret/). If we'd just done it properly the first time then we wouldn't regret the investment we're making now. This is wrong on so many levels. The trick with business is to deliver in a timely fashion, rather than deliver the perfect solution to late for it to be of any use. We engineers see to forget that, driven as we are by the intellectual challenge the creating the perfect solution provides us. http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment18http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment18Wed, 03 Feb 2010 04:17:02 GMTInteresting perspective, although I think you are missing context as the importance of efficiency varies for different classes of software. Admit-tingly most of the time its not important if you're an enterprise developer connecting web apps to a RDBMS. In most of these cases developer efficiency and time to market is more important for a business then time to develop the feature is the only ROI worth measuring. But if you're developing software that is frequently run (i.e. a library or framework developer) or intended to be frequently used on a day-to-day basis than responsiveness and performance is very important for user satisfaction. This is where economies of scale makes sense and it becomes a good candidate for optimization. Also for 'service software' that's needs to be available 24/7, hosted on the internet and available to thousands users efficiency becomes very important. A data-centre on the Internet is much more expensive to run than an in-house server room. You usually need 2 of everything and the cost of bandwidth, power, rack-space, networking equipment, etc. can quickly dwarf the cost of an expert developer. Personally I think performance is highly underrated and the difference of a UI completing in a few ms to one that takes seconds to run is of paramount importance, its usually the difference of software that is a joy to use to one that is not used at all. This is a concept not lost on google where performance and efficiency is paramount. http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment17http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment17Tue, 02 Feb 2010 23:38:25 GMTPremature optimization take us to a more efficient solution AND a bad software too. We are grown people, we are talking about having a well designed software that could be optimized later, not doing something inefficient just because. http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment16http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment16Tue, 02 Feb 2010 20:05:38 GMTEdin, I thought more about ent. scenarios than ISV ones, actually. It is often easier to fix such things in ent. environments. Alex, *sigh*, now you know why I worry about whatever I should post stuff or not. http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment15http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment15Tue, 02 Feb 2010 17:49:23 GMTDhananjay , If your product isn't on the market, your competitors have more than an edge. http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment14http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment14Tue, 02 Feb 2010 17:48:05 GMTFrans, Changing something doesn't imply breaking changes. I release several times a day, sometimes, it works. And if I don't fix it for v2.0, it probably isn't important enough to BE fixed. > Any person who is depending on his/her ISV for income would not make this decision as it likely will not work out as planned. Frans, I make these decisions, all the time. http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment13http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment13Tue, 02 Feb 2010 17:46:31 GMTDon't forget calorie efficiency http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment12http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment12Tue, 02 Feb 2010 15:14:44 GMTNow, with Ayende's blessing, let's go and create some really bad software. http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment11http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment11Tue, 02 Feb 2010 13:55:38 GMTAyende, I guess you're right for ISV scenarios (like for your Profiler). But i'm not sure if the less efficient solution is way to go in enterprise environments. Less efficient solutions might have some hidden costs as well. Typical enterprise applications usually last in decades so investing upstream will eventually pay off downstream. http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment10http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment10Tue, 02 Feb 2010 13:03:11 GMTWon't it give competitors an edge to market their similar products more aggressively? http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment9http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment9Tue, 02 Feb 2010 12:55:36 GMTThis post reminded me of a famous real world example [www.wired.com/magazine/2009/12/fail_duke_nukem/](http://www.wired.com/magazine/2009/12/fail_duke_nukem/)http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment8http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment8Tue, 02 Feb 2010 12:22:47 GMTYou ignored one specific very important issue: every time you release a version, you can't change it later on unless you can break your customer's software. This thus means that whatever you release, it is fixed in time, and will stay there forever. Over time, you'll learn how to do things more efficiently, and then the old api/ the old tools are a burden, because they have to be kept around otherwise your existing customers will be angry and won't upgrade. Another thing is that there might not be time to do research for doing things more efficient because it might very well be you need to release v2 with new features also a.s.a.p. So it's not as simple as deciding to release early and fix inefficiencies later on, that's a very risky choice to make. I don't say you should develop everything as great as a human can possibly make it, but you at least have to realize that fixing it AFTER release is likely not going to happen and likely very difficult to do without creating a lot of problems for your customers. To be blunt: only consultants who have a dayjob would consider this as a viable option. Any person who is depending on his/her ISV for income would not make this decision as it likely will not work out as planned. http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment7http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment7Tue, 02 Feb 2010 12:20:33 GMTI think all developers should work on their own startup or as part of a start up to realise the financial constaints and what the real business concerns are. The goal of building software 90% of the time is to build a product that people will buy to solve their particular problem. Getting products out the door and getting actual and not perceived feedback will inevitably involve incurring technical debt. Too many startups are from developers who ignore marketing and build something that there is not a market for. If your product is not selling then your correct, uber solution will not stand you in good stead. Get version 1 out the door and iterate fast. I am trying to bring products to maket and I have to look at offshore development purely because of economics. I think the craftsmen bores have their heads in the sand if they cannot see the financial constraints that most microisvs are under. http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment6http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment6Tue, 02 Feb 2010 12:10:54 GMT@liviu: You can select the most cost effective route and still create good software. You can compromise on scalability and maintainability. Not so much on customer satisfaction. http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment5http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment5Tue, 02 Feb 2010 12:00:10 GMTI think it's "lame". Companies produce crappy software because they need to deliver quick and get my money. I will get hooked and use their third party tool component, and it will work in their demos, but it will fail in custom scenarios. Sometimes i will have to wait for next version of the software in order to have something functional. The quick decision will be to dump the component. But if you invested enough time to use it and code against it, you will not deliver yourself if you decide to change it. so i will deliver crappy software too. This is the curse of the software industry. We need to deliver shit soon, just let the marketing guys to compensate for the smell. http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment4http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment4Tue, 02 Feb 2010 11:51:23 GMTI agree. The balance between the right technical solution, the time it takes to implement it and the money required to do so should be in the back of every developers mind. Finding the right solution is a challenge however. Following the YAGNI principle can get you far, and the rest, I guess, is left up to experience. http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment3http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment3Tue, 02 Feb 2010 11:43:11 GMTVery well said. We are in the middle of a new project at the moment and we have a deadline to meet. Of course we spend some extra time at the start to make the framework easy to work with but since we have just been implementing features because in the end a 100% finished product that is inefficient and may violate fundamental coding principles is still a product that can be sold and not a half finished piece of art. We have however put in our project plan that soon after release, the code base will be refactored so that changes there after are painless and easily testable. http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment2http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment2Tue, 02 Feb 2010 11:39:49 GMT There is also the aspect of lost sales opportunities: Waiting for the efficient version may result in lost sales up front. Shipping an overly inefficient product may result in lost sales later. Add these realities into the mix, and I tend to support the refactoring path most of the time. http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment1http://ayende.com/4383/it-is-less-expensive-to-do-it-inefficiently#comment1Tue, 02 Feb 2010 11:34:22 GMT