70% of the Software You Build is Wasted (Part 1 of Series of Tool/Platform Rants)
Posted by Bob Warfield on September 4, 2007
The headline gives a gruesome statistic, but it is probably understated. At least 70% of the software you build is wasted because you are constantly reinventing the wheel by building components that do not deliver any competitive differentiation to your offering. You have to build them for the offering to work, but they’re things that everyone in your space also provides. Often, they are things that everyone in every space provides.
I was having lunch with a CTO friend recently and broached this subject to him in a deliberately provocative way. After he got past my delivery, he sighed and commented that he agreed. Every new job he takes requires reinventing the same wheels all over again. Another friend who is a marketing guy had exactly the same reaction even though he isn’t a techie. He knew exactly how much was being invested in Engineering to build stuff that he couldn’t put in a press release or otherwise tout. His referred to this work as a tax on innovation. The non-differentiated stuff would just barely be average if you did it extremely well. It would be average because it didn’t matter that it be any better than average: it wasn’t a competitive differentiator. Therefore you couldn’t afford to make it better than average if you were focusing your business properly.
I find it incredibly bleak to consider that 70% of the lines of code being written will be average at best and will likely make no difference to the business.
Consider the example of Security to give a flavor for what I’m talking about. In the Enterprise World where I’ve spent a lot of my career, Security is a key area of functionality that CIO’s and IT guys want to know about before they’ll even think about buying your product. There is a long list of features and questions they have to be briefed on. How will you interface with our LDAP server? How will you deliver single sign on under our portal standard? Do you support our (1 of 257 distinct formulas we’ve seen so far) exact recipe for how we want passwords and cookies to be handled by thin clients? All of the real offerings need to have good answers for all of these questions, so it’s not giving you any proprietary advantage to solve these problems, it’s just part of the cost of doing business.
For SaaS companies, the tax is even higher. At a perpetual software company, you install inside the firewall. Many security issues for SaaS are taken for granted once you’re inside the firewall. There is a lot of IT glue already in place to enforce things like password policies (it has to change every 90 days except when there is a Harvest Moon, there must be at least 13.5 characters, 1 of which is a symbol from the Greek alphabet, 3 of which are the square root of your Mother’s first pet’s name, yada, yada, yada) and to let other vendors shoulder some of the burden for things like monitoring whether the software is functioning properly. As a SaaS vendor, you have to build all this glue that your perpetual peers take for granted. Is it any wonder that the common wisdom has become that SaaS takes more investment capital?
There are many more examples:
- Forms and UI: Most UI is really pretty similar, with a slightly different application of surface level cosmetics for branding. This is a good thing, because it means you understand the vocabulary if not the language when you see the UI of most web software. Yet, a staggering amount of work goes into recreating this wheel over and over again.
- Database Connections and Persistence: The data goes in a database in most cases, whether we’re talking mySQL or Oracle. Isn’t it amazing how much effort still has to go into this connection lo these many years since E.F. Codd postulated relational databases? And how long have we known that object oriented languages need a way to put objects into the database and then get them back out, something we call a “persistence layer”? Yet, we frequently have to build or at least extensively modify some component to make this happen.
- Reporting, Messaging, Data Feeds, yada, yada, yada. The list of things companies build that already exist in some form or fashion is huge. NIH is alive and well in today’s Software 2.0 world.
- Scalability: Caches and similar contrivances get recreated over and over again as traffic builds up on your web site.
There are many more examples that I’ll leave to the readers. How does this happen? I blame three candidates, one of which is cultural, and the other two are technological, yet enabled by the cultural quirk:
Software Developers are Producers Not Consumers of Code
Code reusability is hard, as anyone who has tried to herd the cats (developers) all together towards some form of reusability or core technology will tell you. Every developer will loudly proclaim that code must be reused. They will immediately follow this up by demanding to work in a core technology group that will produce the greatest code for sharing since sliced bread. What they’re really saying is, “Everyone should reuse code, but it has to be my code they reuse.” Take any software developer who is well regarded by his peers, collect some of his code, destroy all comments and other information that would connect the code to the star, and give the code to another engineer telling him he has to use it or maintain it. The recipient can be a star or just one of the troops in the trenches, it doesn’t matter. In 99 out of 100 cases, the recipient will loudly proclaim that the code is completely unusable and will have to be rewritten.
Programmers hate to reuse code becaues they hate to read and understand code. In the old days it was called “NIH” syndrome.
By now you may be thinking that “Software Developers are Doers, Not Learners”. In practice, I have not found this to be true, but I have found that the organizations the developers work for rarely invest in letting their developers learn, hence the end result is they’re stuck doing the same old think in the same old Curly Braced Language:
The Tyranny of One-Size-Fits-All Curly Brace Languages
If everyone else’s code is crap, which we have established by now, I’d better have a language that lets me write anything, because you never know what I might have to write. I’d better have a curly brace language: a real Alpha Geek’s Power Tool for Programming. The Curly Brace Languages are C++, Java, and C#. They are all descendants of the mighty C language, which was created in 1972 in order to build Unix, an operating system. Because of this, C is considered a Systems Programming Language, although many used it to create Application Software. Because Systems Programming is about creating absolutely the gnarliest, most difficult types of software, such as operating systems and even new language compilers, it has to be able to get down to the finest levels of detail without making any assumptions. It can’t get in your way, in other words. Wikipedia puts it amusingly by saying that System’s Software talks to hardware while Application Software talks to people.
Unfortunately, for that 70% of wheel reinvention I mention above not getting in you way means the Curly Braced Language also doesn’t help you much. You do all the heavy lifting! OTOH, should you need to write code that talks to hardware (does your business really need that?), the Curly Braced Language is indispensible. Blogger Russell Beatie puts it extremely well in Java Needs An Overhaul:
There’s something about the Java culture which just seems to encourage obtuse solutions over simplicity.
It isn’t the culture though; it’s the language that encourages obtuse solutions. It’s deep object oriented programming. It’s the fact that the Curly Brace Languages have become the assembly languages of our day, and there is nothing more obtuse than a big assembly language program. Don’t believe Curly Braces = Assembly Language? Consider the following strengths of Curly Braces, which are essentially the same as assembly language:
– You can talk directly to the hardware (yes, you can do Systems programming, but does your project really need to?)
– Because I get better performance (yes, but not in a multicore world where massive scalability not tight loops will rule)
– Because I might have to do some gnarly cool down-in-the-weeds Geek thing that can only be done by a Curly Brace Language (yes, but how often must you do this?)
Enough said. You can get the job done with Curly Braces, but 70% of your work is wasted because you have an electron microscope when you really needed a pair of reading glasses. Smart companies are now using more than one language, a practice called Polyglot Programming. They know the dangers of overly focusing on a single Curly Braced Language for all programming. I’ll have more to say about Polyglot Programming in a future post.
The Application Framework Tower of Babble
So what happens with my Curly Brace Language when I want to do Application Programming instead of Systems Programming? Well, unless I am crazy enough to ship an OS with my application (don’t laugh, it has been done in the past!), I need help talking to the OS that’s already in place. That’s because the Curly Braced Language is so busy not getting in your way that it doesn’t help you much either. It can talk to your hardware, but scarcely knows your operating system. So, the stuff that isn’t built in comes to you via the Application Framework (what used to be called libraries). Without an Application Framework, Curly Braced Languages can’t do much except write, “Hello, World.” Unfortunately, that’s been done and is no longer monetizable. Time to move on.
App Frameworks are supposed to be standardized so everyone can reuse that code, but fortunately, the best thing about standards is there are so many to choose from. I recently read a 4 part article about Web Application Frameworks for the Python language and lost count of how many different frameworks were mentioned. It was quite a good article, but you get a sense from it that App Frameworks can become another excuse to write more code especially if your language allows it. The other problem with them is they are wicked hard to learn and understand. Learning to write code in C is not bad at all. The original book on C was 272 pages of clear easy to read text. The original tome for learning to write in Microsoft Windows was Charles Petzold’s classic Programming Windows was a dense 1478 pages! Did I mention learning Application Frameworks is hard? That’s 5 times as much reading for the framework as for the language!
Quoting Beattie’s “Java Needs An Overhaul” on Frameworks gives a flavor of what it’s like and why it’s broken:
As a Java developer, I was always so amazed at how difficult it was to use the standard Java Class Libraries for day-to-day tasks. Every app out there ends up having to include 20MB of .jars in order to get even the simplest functionality working because Java libraries are so low-level and incomplete.
What’s worse, is that most of the frameworks are not that well implemented. In fact, there are no great frameworks that solve all the 70% of problems that are the tax we’re talking about here. This forces many large organizations to wind up writing their own framework, thereby empowering the internal crowd who wants code reuse so long as it is their code that is being reused. The proliferation of these frameworks inside large companies is so extreme that the benefits are usually lost. Hence more 70% tax burden.
Hey Wait, What Happened to Object Oriented Programming?
Yessir, making it easier to reuse code was one of the big promises of OOP. I love OOP and have loved it since encountering Smalltalk. I confess I’m an odd soul because LISP was the first programming language I learned, which raises a lot of eyebrows. I was a General in the OOP Wars where Borland C++ battled it out against Microsoft C++. I even ran a startup that sold a Modula-2 compiler of all things, for a little while in the 80’s. OOP is a powerful tool, but I have two criticisms of it. First, as it is traditionally deployed by the Curly Brace Languages, it is incredibly baroque to the point of being extremely powerful yet almost impossible to master. Experienced devotees of the Curly Braced OOP Priesthood will tell you that these constructs are exquisitely precise in letting them refactor their code along whatever architectural designs they desire, but that out of the universe of people who can write code, a much smaller universe can do object oriented programming. This is a shame, because the original concepts for object oriented programming came out of languages like Smalltalk (and Simula) that were designed to make programming approachable by anyone. There is a growing suspicion that OOP really doesn’t help productivity much at all, but I’m not yet ready to enter that camp myself. However, more than one person has said that the reusability of C++ is not significantly better than C, and I am in agreement with that.
The second issue I have is that OOP doesn’t really facilitate code reuse very well. It isn’t service oriented, it’s about controlling the fine grained behavior of objects in intricate ways. In fact, one could argue that it makes a lot of code much harder for someone to read and understand because of all the things that happen implicitly and in many and varied locations. Certainly anyone who has ever walked through a complex inheritance scenario using all the OOP bells and whistles in a Curly Braced langauge on code someone else wrote will tell you it was a harrowing adventure at best. The old computed GOTO in FORTRAN has nothing on OOP when it comes to the power to obscure meaning.
What About Open Source?
Open Source has spawned a lot of code reuse in certain areas, moreso than any other trend I’ve seen in my career. Definitely more than Object Oriented Programming. I think its great, and I am a believer, but it has its limitations too. A lot of Open Source code is intended to be reused as-is or extensively modified. That is, its more like software that’s so cheap you may as well reuse it than software that is designed to be more reusable than other software. Truly resuable code would not need much modification to repurpose it, or the modification involved would be extremely trivial.
That leaves Open Source reusability down to build versus buy. If the code to be reused is suffciently simple to just write, most developers will not select Open Source. If the code is extremely complex, and the economics or schedule do not allow for a rewrite, Open Source comes to the rescue. This tends to push Open Source code sharing more towards the grandiose and away from the prosaic. mySQL would be a heck of a thing for an app company to have to write before it could get on with developing expense reimbursement software.
Given this trade-off, I see most Open Source code reuse as being more a matter of module reuse. Some fairly large and complex Open Sourced subsystem gets packaged up with some glue code and becomes the centerpiece of an important part of an application. That’s great, but it doesn’t seem to whittle much off the 70%.
What’s the Answer?
If you want to quit wasting 70% of your efforts on software, you’re going to have to discover a way to reuse code–preferably reusing code that (Gasp!) other people wrote anyway. Getting back to the service oriented perspective, true code reuse benefits from the service oriented perspective. Forget the Curly Braced Power Tool perspective for a minute. Use the power tools to create the proprietary advantage that you currently only get to spend 30% of your time and resources on. Look for a simpler, service-oriented approach to the 70% of functionality that is undifferentiated. Favor simpler service-oriented approaches without making them too simple as to be unworkable. This will minimize the amount of learning your developers have to do to reuse the code components. This is why REST is rapidly becoming more popular than SOAP as a protocol for Service Oriented Architectures. It’s simpler.
A lot of things succeed because they are simpler. C, in its day, was far simpler than Algol or PL/I or even COBOL. C++ was simpler than the overblown Ada. And Java simplified a lot of the issues that were on the C++ programmer’s mind. Now lately we see that scripting languages like PHP, Python, and Ruby have succeeded well because they’re simpler than the Curly Braced Languages.
There is no one-size fits all, so why not choose a couple of sizes for different occasions? Martin Fowler (author of one of my favorite books on Enterprise Patterns) puts it well when he says, “we will see multiple languages used in projects with people choosing a language for what it can do in the same way that people choose frameworks now.” Or, as the Meme Agora blog puts it, we are entering an era of Polyglot Programming.
PS: While you’re thinking about Polyglot Programming, consider that the Multicore Crisis is going to start kicking sand into a lot of the old machinery sometime soon anyway. The Curly Braced Languages will be the ones hardest hit by it because they’re closest to the cores.
Related Articles:
Who doesn’t love Java? (Part 2 of the Tool/Platform rants)
ESB vs REST (Another Case for Multi-Language Programming)
Java Device Drivers from Sun: For those who don’t think you can talk to hardware in Java, here’s a detailed paper on how it works, and info on the Java Device Driver Kit (JDDK). If you’re uncomfortable reconciling the notion of device drivers running on virtual machines, Sun makes a good case for it. Their argument is that by letting the VM run as part of the kernel, you can create device drivers that are independent of the underlying CPU’s instruction set. This is particularly important to Sun who have both SPARC and x86 to worry about.
Submit to Digg | Submit to Del.icio.us | Submit to StumbleUpon
A Multicore Language Timetable (Waste More Hardware!) « SmoothSpan Blog said
[…] Things Like Air Are On Fire)How to Have a Happy CEO/CTO Marriage (Features vs Scalability)About70% of the Software You Build is Wasted (Part 1 of Series of Tool/Platform Rants)Has Google Turned Into Microsoft?Is ISV Even The Right Term Any More?What Jobs iApology Reveals, […]
Links: September 10, 2007 « SmoothSpan Blog said
[…] Picture of the Multicore CrisisYou’ve Already Had a Multicore Crisis and Just Didn’t Realize It!70% of the Software You Build is Wasted (Part 1 of Series of Tool/Platform Rants)Why Vista? Why Mac? Why Not Web? (Look Out World, Things Like Air Are On Fire)Web 2.0 Personality […]
Who Doesn’t Love Java? (You’d Be Surprised! -and- Part 2 of the Tool/Platform Rants) « SmoothSpan Blog said
[…] productivity and quit “reinventing the wheel”. Translation: They didn’t want 70% of their coding to be wasted. Their presentation on this decision is quite […]
We Are Using Tools That Simply Were Not Made For The Job « SmoothSpan Blog said
[…] So says Albert Wenger on the Union Square blog. Albert has written an excellent variation on my 70% of the software you write is wasted and Multicore Crisis themes. Key areas he brings up as “wasted” work that should be […]
deanjones said
I don’t mean to be rude, but you are bad-mouthing the profession of a large number of people from a position of ignorance, so you should expect to cop some flak. There are a large number of errors of fact that you have made in this article.
You seem to believe that Java and C# allow you to “talk directly to the hardware”. They do not. Both Java and C# run in what is known as a virtual machine (called the JVM and CLR respectively) which means that they can only communicate with the host operating system, not the hardware.
You claim that “a staggering amount of work goes into recreating” UI components. UI toolkits have been available for something like 20 years now, and have increased in sophistication over that time. A UI toolkit typically includes all of the components that are used to compose a user interface. There are even numerous Web 2.0, funky Ajax UI toolkits available (too many to count, actually). This means that the average UI developer spends no time creating these components, but rather assembling them into an application. Isn’t code re-use fun?
You claim that “caches and similar contrivances get recreated over and over again as traffic builds up on your web site”. There are a large number of caching solutions available. Some are open-source, some are commercial products. Many (most?) are written in object-oriented languages. Anyone who writes a new caching layer when developing a new application is probably not doing their job properly.
You claim that “C, in its day, was far simpler than Algol or PL/I or even COBOL. C++ was simpler than the overblown Ada”. This statement suggests that you have never coded in any of these languages and therefore are not really in a position to comment on their relative simplicity.
You state that open source has “definitely” spawned more code re-use than object-oriented programming, thereby confusing two completely orthogonal concepts. Many, many open source projects are written in object-oriented languages.
You state that “70% of the Software You Build is Wasted” but do not include a reference to the research that demonstrated this to be true.
As I say, I don’t mean to be rude, but I think it’s pretty rude of you to criticise software developers when you know so very little about software development.
smoothspan said
Dean, welcome to the discussion!
Let’s talk about your “errors of fact”:
First, let’s get your argument that I know very little about software right out of the way. I’ve written a ton of software in all the languages I’m talking about except C#. I’ve written all the types of components we’re discussing from low level allocators and overlay managers right up to application software involving genetic algorithms. I’ve built compilers and interpreters, so I know languages. I’ve built user interfaces and high performance grid-based enterprise architectures. I’ve managed organziations large and small that build software products including Borland during the heyday of Turbo C++ and Delphi. And, FWIW, I have a degree in Computer Science and I hold a number of patents on software inventions. Finally, on this subject, I’ve also had the benefit of talking to many peers who are engineering managers and architects in commercial ISV’s. That stuff is all easy to check out on the Internet, so you ought to do that the next time you want to tell someone what their credentials are. Fear not, though, all is forgiven.
Next, on whether Java or C# can talk to the hardware. They absolutely can! In fact, Sun offers a Java Device Driver toolkit. You don’t get much closer to the hardware then writing device drivers! For more, just Google for “java device driver”. Embedded systems are another category that is very close to the hardware that you can tackle with either language. I’m not the first or the last to call them portable assembly languages because the same fits, and its no knock on the languages, so you shouldn’t take offense!
On to recreating UI components. In many ways you make my point for me. Yes, there are tons of libraries and toolkits out there. But let me ask you this, if they cover all the bases and everyone is faithfully using them, why is there so much interest in Adobe’s Thermo which let’s you create (drumroll please) more UI components? Have you really never worked on a piece of software that had you creating yet another UI component, particularly a form or other complex object that required a lot of programming?
Caching is a similar phenomenon. I can’t believe you’ve written anything highly scalable and performance intensive that didn’t benefit from some kind of cache, and that the cache in the library was so spot on you never wrote any caching code. Yes, there are again many libraries out there. I’ve written about memcached right here in this blog, for example, and its a great piece of reusable technology. But these wheels are reinvented in various form or fashion many times over. You can hardly pick up a paper on a performance intensive piece of software such as Amazon’s Dynamo without reading about the fancy caching they built for performance. If it’s all right there, why all the interest and coding around fitting a cache to some aspect of an architecture?
You appear to suggest that C is not far simpler than Algol, PL/I, or COBOL. Really? Have you ever read the Language Reference Manual for PL/I? I did. It’s waaayyyyy longer than the C book!
Lastly, on the question of whether open source spawns more code re-use than OOP, look at it this way. Open sourcing any body of code exposes it to a larger audience than the alternative, which is code that is developed and used inside a single organization. Whether the particular body of code is object oriented or not, how could you quarrel that open source isn’t reused more simply because the audience is so much bigger? Now I do know a thing or two about code developed inside organizations and its reuse, and I have to tell you the statement that open source has seen more reuse than OOP is not controversial at all to that experience or too my peers who are VP’s of Engineering all over Silicon Valley. Most people I know are extremely excited by open source precisely because of its potential reusability in their projects.
The real mystery here is why you find the article to be personally insulting? When I talk about it directly with people, they sigh and agree. They’re tired of reinventing wheels. They aren’t angry, just tired and want something better. It isn’t a language war issue either. They like their curly braced languages as do I. But they also readily admit those languages often don’t help them as much as they’d like and that code reuse is really really hard. They don’t take any of this personally because they’re the ones down in the trenches suffering for it. Isn’t it worth a dialog to figure out how to reduce that suffering?
Cheers!
BW
smex said
The MultiCore problem will be solved. The Task Parallel Library, from Microsoft, provides optimized managed code for multi-core processors using a new thread pool that supports cancellation, waiting, pool isolation, which uses techniques from The Cilk Project from MIT and a Dynamic-Sized Nonblocking Work Stealing Deque from Sun Microsystems for scalability.
Parallel LINQ provides an implementation of LINQ-to-Objects and LINQ-to-XML which allow LINQ queries to utilize all of the CPUs or cores to get the job done by making use of data parallelism internally. Parallel LINQ supports the full set of LINQ operators and provides several ways to consume the output in parallel.
University of Maryland has also made some progress in making MultiCore useful for general computing. A plethora of other companies and universities are making good progress here. You might want to revisit this and determine for yourself if this will be an issue for much longer.
deanjones said
Hello again,
I just want to come back on your response, then I promise that I’ll stop bugging you 🙂 I also want to re-iterate that I don’t mean to be rude, but I do disagree with much of your article, so it may come across like that; please don’t take offence.
I think it’s really misleading to characterise VM-based languages such as Java or C# as systems languages? I’d be extremely surprised if there was a single device driver used in any of the major OSes that is written in Java or C#.
Also, I didn’t say that I believe C to be more or less simple than Algol, etc. I just don’t believe that it’s helpful or possible to baldly state that any of these languages is simpler than the others. How would you go about objectively measuring the relative simplicity of such languages? It’s the assertion that such a comparison is possible or relevant that seems odd.
Also, I’m not arguing that open-source software is re-used less or more than OO code – my point is that it’s a false dichotomy to compare the two.
On the subject of caching, I have indeed used caching libraries and not had to write a line of code to do so. Modern application servers and dependency injection frameworks make it extremely simple to configure caching options without having to write code. I’m sure you remember the days when every project wrote their own poorly-implemented cache, but things really have moved on since then. Caches really can be reasonably easily plugged into an application.
One of the main reasons for this level of re-use is the widespread use of object-oriented code. Believe me, I’m not the biggest OO fan in the world but we have to recognise the huge benefits that OO languages like Java and C# have brought in terms of the amount of re-use that is being done these days. I find that on a typical project, we re-use between 50 and 100 third-party libraries; this level of re-use has mainly (possibly only) been enabled by the use of OO languages.
Nobody is saying that the current situation is perfect or that more re-use is not possible, but I believe that the main inference you draw – that the lack of re-use is somehow due to the widespread use of OO-languages such as C++, Java and C# – is just plain wrong. Software development has changed a lot in the last 10 years and code is re-used much more than it used to be.
Best wishes,
Dean.
smoothspan said
Well Dean, it seems we’re now mostly into the territory of degree and semantics, so I think our journey is nearly done. By degree and semantics, one example is that while you’ve not heard of a device driver in common use written in Java, you’re now prepared to admit it wasn’t so crazy to suggest it could be done. Rather than debate whether Java is a systems language further, let me just say that the Java community I frequent writes a lot of systems software with it, as well as a lot of applications software.
RE which language is simpler, I won’t be the first to speak in these terms. They’re not objectively quantiable, but they’re certainly subjectively quantifiable based on how hard the languages are too learn, how much material there is to wade through, what difficult concepts they embody, and so forth. This is not an unusual way to talk about languages, and the comparisons I’ve made are not particularly controversial. Even the Wikipedia refers to Java as having a simpler object model.
On reuse, we’ll continue to disagree. OO is not orthogonal to reuse, but at the same time, there is a huge body that indicates it’s no silver bullet. There is also a huge body that indicates wheels are constantly being reinvented in every area. What else are Design Patterns but minor cogs called out so they can be reinvented more easily? It’s helpful that we have standardize the general specification of the wheel to a design pattern, but fairly annoying that it continues to be such a manual process to reapply the pattern, and more interestingly, that different patterns seem to be required in different languages.
Still in all, we haven’t touched on the two more important elements, run time libraries (there are too many and they are too hard) or the human/cultural issues that are the most profound of all. On that, I agree that people are more important than any single language. I just think that if all you have is a hammer, everything is a nail.
Try some other tools out. It’s broadening. Nice thread elsewhere in the blogosphere on how trying other languages even helps you come back to the old languages and do better.
Cheers!
BW
smoothspan said
Smex, I hope you are right that the multicore solution is right around the corner. I’m frankly dubious about that one. Having built a lot of highly scalable distributed software, the thread libraries you speak of are not a panacea. They’re cool, and they beat no threading, but look at more massively scalable architectures such as Amazon writes about on Dynamo, or the things you read on the HighScalability blog.
It’s gonna take more than throwing a few threads at the problem to make it go away!
Cheers,
BW
ESB vs REST (Another Case for Multi-Language Programming) « SmoothSpan Blog said
[…] Comments barmijo on The Perils of Platform as a Se…70% of the Software … on ESB vs REST (Another Case for …Who Doesn’t Lo… on ESB vs REST (Another Case for …ESB […]
New Paradigms for Developer Thinking: Spatial Synthesis « SmoothSpan Blog said
[…] Posts 70% of the Software You Build is Wasted (Part 1 of Series of Tool/Platform Rants)Who Doesn’t Love Java? (You’d Be Surprised! -and- Part 2 of the Tool/Platform Rants)The Perils of […]
thak’s cool links » 70% of the Software You Build is Wasted said
[…] 70% of the Software You Build is Wasted « SmoothSpan Blog. Fabulous article. […]
braces » 70% of the Software You Build is Wasted (Part 1 of Series of Tool … said
[…] Read the rest of this great post here […]
Software Development Guide said
Software Development Guide
I couldn’t understand some parts of this article, but it sounds interesting
Andrew Biss said
Hi Bob,
Good post.
Another aspect I would add to the discussion is that vertical ISVs moving to SaaS must accept that the value they bring to their customers is their domain knowledge. The game is different for horizontal players, but for vertical ISVs the value is in their domain knowledge. Without this what is the competitive advantage they have to offer?
In the past the specific domain knowledge was mixed in with a lot of supporting technology – the 70% you mention – but this drops out of the value equation with SaaS.
As a tool vendor in a previous life it was always difficult to get customers to accept the concept of using a framework for the “common stuff”. They were always looking for reasons why they had to develop these common functions themselves.
The increasing use of LAMP has killed once and for all the argument that ISVs should be involved with system software or horizontal infrastructure products. The next step is to move up the software stack and start to treat all of the common functionality as commodity infrastructure and just buy it in as a service.
In my experience many ISVs have difficulties with this point of view. However, to survive the shift to SaaS they are going to have to accept this once and for all. There is no scope in SaaS for reinventing the wheel yet again. It takes far too long and the economics just do not work.
Hopefully SaaS can kill this on-going debate and we can avoid an on-going “religious war” about specific development languages.
Regards,
Andrew.