Software Development? We’re Doing it Wrong.

By Eran Galperin
We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now

“You are wasting an outlandish amount of money writing code that already exists”

Joel Spolsky, Fogcreek, StackOverflow

In software development, we like to throw acronyms around, such as DRY, KISS and OAOO, which stand for supposedly better practices that lead to a more effective development process. But is the process used to develop software today really efficient?

Code reuse is largely accepted as “best practice” in our industry. Code reuse has many advantages, such as a smaller code-base which is easier to grok for developers. It’s easier to maintain and optimize, since you can make less changes in order to achieve the desired results. Many modern techniques and tools were created in order to better reuse and modularize code.

But while we’re reusing code, we’re duplicating effort. The same code is being written over and over in different places, wasting time and money.

As much as we’d like to think it, our industry is not yet mature.

Custom development should be the last resort

When you look at more mature industries, such as the auto industry, no-one makes their own screws, or their own wheels, pipes and so forth – they buy off-the-shelf components, which are mass manufactured by companies that know how to make those products best. This leads to both better products – through years of field testing and experience – and to much lower costs.

Do you think the auto industry would be profitable if they produced every (or any) component from scratch and by hand? So how come we have this very process in the software industry, only we call it “custom development”?

As software developers, we pride ourselves on our skills. We want to develop stuff from scratch, because that is often the interesting part. But – every piece of code that solves a problem that had already been solved, is wasted effort.

For our industry to become mature and take the next step in both innovation and cost effectiveness, we need to rethink some of the processes we use today.

The future of the industry is component based development

Enter open-source

Open-source is one of the greatest innovations our industry has experienced in the short time it’s been around. Open-source offers standard source-code solutions for many common problems, and has revolutionized the industry with products such as Linux, MySQL, Apache and others.

Free, open-source libraries and frameworks exist for almost every major programming language and platform. The amount of code that is available is huge and benefits the software on many levels: aside from significantly reducing the time needed to build many products, developers are basically sharing their experience and knowledge through the availability of their code. Becoming a programmer today has become much easier in many ways because of open-source.

Still a huge divide between open-source and commercial software

So why isn’t every common need met by an available open-source solution?

There are a few reasons for that:

  • Most open-source projects are created on developers’ free time and good will – developers who have day jobs or work freelance to make a living. Unless they catch major traction, they remain side-projects that are often abandoned gradually until they are not supported in practice. Only 7% of open-source projects are actively maintained.
  • Anyone can publish an open-source project – there is no quality assurance or guarantee that it’ll meet certain standards. Many amateur developers get started by publishing open-source projects before they can produce a solution that could become an industry standard.
  • Discovery is a problem – due to the long tail of abandoned projects and varying quality, unless the project is visible and well known, many developers will prefer to develop a solution themselves.
  • As widespread as it is, open-source still covers a relatively small proportion of common needs in software development. There are so many more needs than solutions that custom development is often the only option.

If all the code written for commercial products was repackaged and released as small open-source projects, then we would have already a solution for most common needs.

That is unlikely to happen though – the sharing incentive just isn’t strong enough for most people. It’s similar to the participation in generated content sites such as wikipedia – only 1% of the audience is actively creating while the others merely consume.

An evolved model – Commercial open-source

So where do we see the industry going in order to break through and become more standardized and streamlined? The answer, in my opinion, is provided by products such as MySQL, RedHat and Magento, which use a business model we like to call commercial open-source.

Those products successfully built a commercial model around open-source, by either dual-licensing (free version + premium version), offering paid support and updates, or variations thereof.

I believe that building a viable business case around the release of source-code projects is the only repeatable and sustainable model for most open-source projects, and this is the direction in which the industry will move in the next couple of years. As releasing code become a viable business, several positive things will happen:

  • Open-source projects will be much more actively maintained. If you can support yourself by supporting your own personal projects instead of doing contract client work or working as a hired man in a company, I think it’s a no-brainer.
  • Much more code will be released into the market. This is a very important point – in my opinion, the amount of available, ready-to-use solutions will grow by a factor of 10. So, while individual solutions will cost more than free, the overall cost reduction to software projects – compared to the cost that would be spent custom-developing those solutions – would be enormous.
  • Once you turn the maintenance of open-source into a business, expectations also rise. I expect increased overall quality as well as curation services that help determine which projects have a quality code-base as a reference for developers.

An evolution is occurring, whether you like it or not

I have witnessed what I’ve written about here many times over years as a software developer and the founder of a development firm.

It is what I learned that spurred me to co-found Binpress, a discovery service and marketplace for source-code. I believe this is how relevant source-code solutions will be found in the future.

By curating the code and adding a supporting commercial layer around it, we are trying to evangelize this approach and help make it a reality.

I realize that there is a strong ideological resistance to this kind of movement. Open-source was originally created according to an ideal – which I can only marvel at and applaud, having been so successful in an ecosystem that is mostly motivated by a capitalistic approach.

I do think, though, that as an ideal, we’ve seen the best that open-source can do. The acknowledged successes will be very hard to replicate.

What we have currently is increasing noise, as more and more people have easier access to start programming and publishing their projects. We need to streamline the process and add that missing financial element that makes it sustainable and repeatable.

I’m sure you have your own opinion to offer on this subject, and would love to discuss it in the comments.

We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now
  • As it gets easier for devs to spin up google code repos or github accounts, open source foundations like and the Apache Software Foundation will help filter the signal projects from the rest of the noise via project incubation. Software projects from Google, Oracle, and Adobe have been passed to the ASF recently, and I hope the trend continues.

  • Open Source is a wonderful concept… For the other guys. I’ve been developing software for over 45 years, and the rise in available open source components is a great help in projects, and I really appreciate the “gifts”. But I am not personally interested in giving away my efforts when I can sell my services instead.

    That is different for Google, as it could be different for Apple or Microsoft. These huge companies can benefit from having at least some of their software production be given to developers to extend what the giving company needs to be done. That was Microsoft’s objective when they produced the first “C” compilers and Visual Basic Compilers for $99. Every High School kid now had tools to write the next blockbuster Application.

    These days, it is difficult for developers, at least completely independent ones, to make a living. I have little temptation to give my efforts away.

    Open Source, at its best, needs first to have a “sponsor”, probably a group of wealthy sponsors, who fund a project to make a particular product, that then is administered as “open source”. Then like any other quality code, it needs to be maintained in a quality fashion by learned professionals compensated for their efforts..

    Anything else results in the 93% of lost efforts referenced in the article.

    Google’s donations to “Open Source” are invaluable to the industry, but they also result invariably in Google’s name also being displayed on, and by, any use of the materials. It is no accident that folks say “Google it” rather than “do a search”.

    Bud Jay

    • I completely agree with you Bud, and that is the main position I’m proposing in this article. Open-source projects need to be sponsored, and not just given away for free. Providing commercial licenses to source-code creates both a revenue stream for the developer and an obligation to the consumer – win / win for both sides.

  • Are we addressing the real problem? Is C#, Java or PHP so much better than COBOL when it comes to writing a business application? Yes and no. Yes it is much better, but no, it is not 100 times better. So in the last 30 years we have only been able to improve the programming process by maybe 10 times. Sounds like a lot, but it is not. I have used code generation tools like GeneXus (see that use business rules instead of regular programming code very successfully, but the market has not embraced them. Why? I don’t know. Probably if one of these small companies was acquired by Microsoft, Oracle or another large software organization, they could become mainstream. For now, we will have to continue to write code that looks like code instead of business rules.

  • A few responses:

    “The future of the industry is component based development”.
    That is also its past, all the way back to the client-server model and the earliest releases of Windows. Most code reuse strategies are and always have been implemented around generalising and packaging well-defined, loosely-coupled black boxes of code. However, your chosen platform or framework also has to support components with public, discoverable interfaces, which usually means an OOP environment. This is not always the case; for instance languages that are commonly considered FP langauges (e.g. Erlang, JavaScript) support code reuse through different mechanisms.

    “Anyone can publish an open-source project – there is no quality assurance or guarantee that it’ll meet certain standards”
    Actually, one of the great strengths of the open source development model is its quality assurance, through constant code supervision by many eyes and testing by many hands. Arguably, most open source code is generally better QA’d than most proprietary code.

    “If you can support yourself by supporting your own personal projects instead of doing contract client work or working as a hired man in a company, I think it’s a no-brainer.”
    In my experience, most real innovation in IT systems is driven by customers, not isolated IT developers. Customers provide two crucial missing ingredients that no IT developer can produce unaided: realistic use cases, and antagonistic testing under stress. My view is that developers don’t find out how good they really are (or aren’t), until they have to meet real-world requirements at a hot, sweaty, live customer site.

    There are now many source code repositories, some of which are operating various revenue models, e.g. SourceForge, Koders, Ohloh, Snipplr, BitBucket, GitHub, CodePlex, Maven repos, icontem’s class repo sites etc. We are already spoiled for choice. But I wish you the best of luck in your efforts to provide a new income stream for open source developers.

    • Thanks for the insights, Russel.

      I think differently from you on most of the points you raised – for example, most real innovations are never customer driven. The customer only knows what he needs in relation to what he knows. No customer could invent the computer, the Internet or the iPhone. Those advanced come from true visionaries. Customers can only improve existing products, never create new ones.

      Regarding your claim to open-source being better QA’ed than proprietary software – that is more a myth than fact. Popular projects do get more QA, but lesser projects get almost no feedback. Our goal is to have a developer committed to providing support through the lifetime of the project, by having those with the financial ability (companies, professional developers) back up his efforts.

      And for the last point – of course I’m aware there are many code repositories. We are inherently different from the other open-source directories in several aspects –
      1. We curate every package. Only packages meeting coding standards for their platforms are approved. The biggest problem on the large directories is noise – you have over 2 million repositories on Github, and it’s becoming increasingly hard to find what you need there.
      2. We provide the ability to add commercial licenses in order to support continued development and support of projects.
      3. We provide marketing and distribution help, in order to help developers reach their audience.

      I believe the difference is significant, and we are targeting a somewhat different audience.

  • Meanwhile I agree that open-source is great, but as pointed, many amateur developers released their code, and left as it. The result is many security holes was released too. As a hosting provider, I see this many times. Even with script likes WordPress, people write themes for it, then your Wordpres-based website is defaced, just by using that such a bad theme.

    I wonder if there is any rule that amateur developers can follow, that can help to reduce security issues?

    • There is no specific rule – they just need to better educate themselves. Everyone starts at the same pole position, just a question of whether they are willing to learn.

  • Halil

    I think one of the biggest differences from auto industry is expectations and standards. The use cases and basic mechanism of nearly every car is very well defined and has been quite the same for decades. This makes it possible to build a continuous streamlined process where mots parts, producers and their properties are well known.

    But software industry seems quite a bit different. Software is not used only for some very well defined purposes, but rather it is used for nearly everything on earth. Because of this, we may still be quite different from the auto industry in the future as well.

    Yet again, I too believe we are still writing existing code for most of the time :)

    • I agree the comparison is not completely identical, but if you break down software into small enough parts – to a point that they’re well defined and can be replaced, you’d notice the similarities are bigger than you think.

      Even if the whole has completely different purpose, many of the parts that build the finished product have been done many times in the past – and can be replaced with standard components.

      • If you break down software into small enough parts, you end up with separate lines of code!

  • Alan Gibson

    I’m not sure I’d agree that customers drive innovation … but they certainly drive requirements.

    If you’re developing a “utility” package like accounting or human resources then I agree that pulling together lots of pre-built, standard components is a good fit. But if the customer wants something that will improve their business or set them apart then their requirements are going to be different from the last customer you dealt with (Martin Fowler calls this the UtilityVsStrategicDichotomy). When that happens, you will often find the existing components and frameworks become a hindrance as they will support 90% of what you want to do, but not the last 10%. If the code is truly open source you could enhance it yourself (and even feed the improvements back) but I would only do that if the source has been developed to very high standards and has an automated test suite included … in other words it was developed using TDD.

    In terms of the comparison with the auto motive industry … I’m not sure that works. As a previous commenter said, cars are cars … they all do basically the same thing and you can churn them out on a production line. Software just isn’t like that … if it was we’d all be out of a job and there would only be a relatively small number of companies building software and selling it in showrooms … like in the car industry!

  • While code reuse should always be a top priority, software development is not like other manufacturing industries. Using screws as an example, every type does the same job. The dimensions and materials vary, but no one creates their own screws because a usable one will already exist.

    Software components, however, have infinite varieties and possibilities. A component may do 80% of what you need, but every developer’s 80% is different and completing the last 20% is difficult. In addition, software standards are more variable because the technology changes rapidly. Ten years ago, we built web applications for the only ‘standard’ browser – IE6. And we know how that turned out.

    If we disregard budgetary constraints for the moment, real-world product manufacturing is limited by the laws of physics and material availability. Software development is limited by your own imagination. For that reason, software component reuse will always be more limited – no matter how it’s distributed, marketed or monetized.

    • Having been developing software for almost a decade, I can safely say that those 80% are not really different aside from some superficial details. If the code is good, it can be reused. I’ve built over 15 web services and application in the last 4 years, with extremely diverse range – athlete-coach management platform, hosted project management, hotel reservation system, online currency auctions and many others.

      I have successfully reused a very large portion of my code base for each, because many functions are shared despite a completely different core concept – features such as user management, integration with various APIs, social sharing features, statistics, content management and so forth. The result is that a lot of work has been saved.

      I think it’s foolhardy to assume your 80% is different from every other developer. And there is no reason the last 20% should be more difficult than the first 80%. In the end, we want to release software products, instead of trying to reinvent the wheel. Our goal should be to reduce the time and costs for doing so, and component based development is where I believe it’s headed to.

      • I totally agree reuse should be encouraged and good developers do it. But am I using the ASP and Perl components I wrote in 1998? Am I using the JavaScript or PHP3 functions I wrote in 2001 or the PHP4 classes I wrote in 2005? Did I foresee the rise of Ajax, MVC, REST, responsive design, NoSQL or Ruby? Even basic components such as user management have evolved with OAuth and other authentication methods.

        The problems are:
        1. Unlike other industries, software design and development is infinitely variable.
        2. The technologies and techniques change rapidly. Screws rarely need updating but components you write today can be obsolete within a matter of months.
        3. It’s usually easier to write your own code than adapt someone else’s.
        4. Developers care more about developing code than reducing timescales and costs – otherwise they’d be project managers or accountants.
        5. All code is crap – you can always invent a better wheel.

        Many companies have claimed to have created modular building-block development systems which allow rapid application development. But, if it were quick and easy to bolt per-built components together, why are developers still in demand?

        Ironically, by pushing for shorter timescales, your developers won’t have time to create quality reusable code. At the other end of the scale, if they’re given unlimited time, they’ll never deliver because code can always be improved.

        Good developers know it’s a balancing act. Sometimes a component can be reused. Sometimes it can be adapted. Sometimes it’s quicker and easier to start again.

    • it seems 3rd level comments cannot be replied to, so I’ll reply to your latest comment here.

      The comparison to the auto industry that I used, is a metaphor. Obviously, it is not a 1-to-1 comparison. Yes, software products are more flexible and varied than cars, but in correlation code is also much more flexible than screws and pipes which are hard steel.

      One of my main points, is that our goal as software developers should not be to always push for better code that does not provide concrete benefits to the end product. It’s very hard to tell when code becomes over designed in preparation for future use-cases which might never happen – so my personal opinion is that it should get to a “good enough”, clean state and be used until it cannot meet requirements or holds up development. With this viewpoint, there is almost never a good case for re-inventing the wheel – other than to satisfy the developer’s curiousity and ego. It has no benefit to the product being developed, unless requirements are not being met by the currently available code.

      I am not pushing for shorter timelines at the expense of quality – but rather at the expense of custom developing available solutions. Using stable, tested source-code components should actually increase quality and reduce QA, as those products have been field tested and should be relatively free of bugs – as we all know, new code will never be.

      • While I understand your point, the best developers are curious about new technologies and push the boundaries of their abilities and code. Some may consider that egotistical, but software development is an art which requires experience, experimentation and refinement.

        Do you want knowledgeable developers or cut and paste monkeys? It’s probably good to have a few of both, but the good ones are unlikely to stick around for long.

    • Being curious and experimenting is good for side projects, but when you’re talking about developing commercial projects, I think it’s prudent to use the best tools available – including available code-bases that save development time. Obviously, today you can’t find good solutions for most of your requirements, but I believe in the future the industry will move more and more to having good, reusable solutions for all common requirements.

      • And that, I think, is the problem: there is no such thing as a “common component”. There is common functionality, but an infinite number of implementations are possible while the solutions available are finite.

        It also depends on your definition of a “component”. Few developers write their own database systems or JavaScript libraries and most have pre-written classes and snippets libraries. Reuse already happens, but it gets far more problematical as you move into higher-level components which implement sophisticated functionality.

        Finally, let’s not forget licensing. Use of some open source components require the final application to be open-sourced or, at the very least, any component modifications to be released. Are your clients happy about that?

    • I think the proliferation and increasing use of open-source packages as replacement for custom development proves that there are many common components and similar code that many projects can benefit from. I think anyone who has reused his own code in more than one project can attest to that.

      My definition of a component is a self contained piece of code (a collection of classes, functions and other constructs) that performs a specific task well and is not trivial to implement. Components can be used in multiple scenarios and projects. Any piece of code that can be separated from project specific bindings can be packaged as a component.

      Regrading licensing – you are completely right. This is why we provide a license generator that can be used to create custom licenses that fit multiple requirements and needs. We advise our publishers to add at least one commercial license in order to give options to potential users who cannot use problematic open-source licenses in their code (such as GPL licenses).

  • As you point out only 7% of open-source projects are maintained. Does your targeted open-source libraries and framework solution(s) conform to your current enterprise information technology infrastructure or will an investment have to be made to augment your current environment? When studying and evaluating open-source solutions you must determine their relevancy with current and future evolution of information technology infrastructure, platforms, software, applications, security and administration management. You must consider what time and investment must be made to develop and integrate your own unique business model solutions with your targeted open-source libraries and framework. Is Service-Oriented Architecture part of your Capability Matuarity Model Integration for maintenance, configuration management, and change control? What is your true Total Cost of Ownership of this integrated solution and what Return On Investment can you expect as a business investment?

  • Anonymous

    “Those products successfully built a commercial model around open-source, by either dual-licensing (free version + premium version), offering paid support and updates, or variations thereof.”

    Yes, but most companies and their developers produce work that applies to their specific industries. They’re in the auto business, or the hotel business, or the airline business.

    They’re not going to jump into the software business just in case some other competitor wants to use their code. Speaking of which…

    Often, many corporate IT systems are viewed as competitive advantages. If, for example, FedEX has a better truck routing and delivery management system, then that puts them one up over UPS and the USPS.

    They’re not going to give that stuff away just for some consulting and support fees.

    • From my experience, most software houses develop for external industries they have no vested interest in. Most non-software companies do not have an in-house development department, and out-source it to software companies.

      And regardless, other than algorithms, most code is not hard to reproduce – only time consuming. I wouldn’t consider that a competitive advantage. I can relate directly to the hotel business since I have experience with that – most reservation sites offer the exact same features, and I can guarantee you most of them got their system from the same providers. The only ways for them to innovate and create a competitive advantage is through better costumer service and superior user interface. The backend is of no concern to the end user, so there is no competitive advantage there.

      Tracking system are the same – it is not hard to write such systems, the main thing is the company’s commitment to updating the status of the packages. That is something that is outside the realm of code, and is not relevant for this discussion.

      • Michael Long

        “… out-source it to software companies…”

        Then those companies are either one-trick pony shops (ERT, insurance claim management, inventory management) or they do custom development.

        Now, in the first case, they make a living selling and customizing their ERT system for clients. Are they going to open-source that code base so that THEIR competitors can snarf it and compete against them?

        And if they do custom development, then the CUSTOMER owns that code in a work-for-hire arrangement, and as such it can’t be open-sourced.

        Look. A few years ago we had some language extensions we developed and thought that perhaps we could make a living licensing them to other folk. Start licensing and selling software, however, and the people you sell to start thinking they’re entitled to support and bug fixes and enhancements and releases.

        Pretty soon, your little side project becomes it’s own entity, consuming time and resources that are often needed for real products and real customers. You know, the thing we started doing in the first place.

        IBM and Oracle and Google may have the resources to devote to such things. Most smaller organizations do not. (Actually, the fact that Google is shutting down lab experiments and APIs suggest that they don’t have the resources either.)

        Suggesting that everyone get into the commercial open-source business is simply misguided. Now, if someone wants to start a MySQL-like support business, that’s a different kettle of fish.

        But the key to success in most organizations lies in a laser-like focus on your core strengths, while eliminating distractions.

        This is a distraction.

    • Replying to your comment below, as you can’t reply to 3rd level comments –

      I basically have answers to all of the hurdles you mentioned, since this is what I do for a living nowadays – but the main thing is, open-sourcing is not for everyone, obviously. Some might find it a viable business model and some don’t. I’m of the opinion that as we move forward, more and more code will be available as (commercial) open-source, and that is for the good of the industry.

      • Michael Long

        “… since this is what I do for a living nowadays …”

        You might leave out the “appeal to authority,” as SitePoint is a development site frequented by those also in the business, as it were.

        And as I pointed out, based on my 35 years of experience (grin), commercial open-source is definitely not for everyone, nor do I think it’s for the majority. You need the right kind of project, of a certain level of complexity, of wide enough appeal, in order to make the numbers work out.

    • Yes, of course, I wasn’t attempting to claim authority on software development – obviously, all the readers here are developers and likely many are more knowledgeable than me :)

      I was referring to my experience as the founder of source-code marketplace, and dealing with the expectations with both sides of the process – publishers and consumers. I see the kind of points you raise on a daily basis, and have good answers since I’ve given it much thought already. That is only what I mean, I apologize if it came off otherwise.

  • Aaron I have to agree with the general tone and sentiment of a lot of the replies here and disagree with you. In you retorts you don’t seem to distinguish between code that you’ve written and the “best available code” “out there”; there are two very different things.

    Code reuse is fine and dandy, no one is going to disagree with you there, and I don’t even think that what you’re saying is that revolutionary. However, I take issue with the idea that tons of developers out there are wasting time “reinventing the wheel”, whatever that means. As someone who is fortunate enough to work for a company that is scaling right now, no one I work with has ever tried to reinvent the wheel, however we are constantly pass-blocking on getting punched in the gut by our massive user base. We improvise and need to be ingenious almost all the time, and there are lots of us doing it at once.

    We’ve been screwed several times now by developers who simply “copied and pasted” code to solve a problem, which seems to work at first, but then it gets hit hard and all of sudden it needs to work for 1,000 people every second and the code they used doesn’t work, because they didn’t implement it properly. Understanding the code you use is key to not be up for 48 hours straight trying to figure out how to get your servers back up and running. I’d much rather be granted a week to “reinvent the wheel” and know that my code is bullet proof and ready to be extended on a moments notice than spend a week trying to figure out something I hacked together. Obviously there is a balancing act to be had, but I think you fundamental accusation/claim is wrong.

    • I feel there is some sort of dissonance here. I am not promoting “copy-and-paste” techniques – I would be the last to promote that. Re-using available code components is just the opposite of copy-pasting code. Copy-paste implies using the same code several times in the same project, with no re-use.

      Do you use frameworks or libraries? how about popular open-source API wrappers? do you call that “hacking something together”? I really don’t see how you can make that claim. How about open-source database or operating system? would you like to build that from scratch? suppose you stumble into an issue with the database that is running your servers, would you next write a database from scratch in order to avoid that situation?

      It sounds to me like you are basically discounting the concept of open-source, even though it’s been proven time and time again, and has revolutionized the industry. Personally, I’d take much more stock in using code that has been field tested by many people, than code that I only I tested and has probably not encountered many edge cases.

      I also think you missed the part about my article that is different from conventional open-source approach – and that is the part about creating a commercial economy around it. If you think that is not different at all from free open-source – that is your prerogative. Most open-source supporters would disagree.

  • I wrote an operating system including compiler from scratch. I created a nonASCII document format for code, help, dialogs, everything that is seamlessly integrated through-out the tool chain.

    Some people want equal distribution of wealth, however, only a billionare can come-up with money to start an airline.

  • Great article and discussion.

    I actually made a whole mini-site a while back called “Doing it wrong” touching on some of the same topics —

    • Lots of good insights there, Jason, thanks for the link

  • Lots of good insights there, Jason, thanks for the link. I believe the difference is significant, and we are targeting a somewhat different audience.

  • Assuming that you are correct and that the industry does indeed need to move towards a more “component” driven model, are you not also suggesting that there we are perhaps at peak demand for developers – more code that is shared means that less code is ultimately needed – hence less developers needed.

    Great article btw.

    • Thanks, Alex.

      I don’t think we are anywhere near peak demand for developers – software is invading every aspect of our lives, and it just keeps getting more complicated. Moving to a more component oriented approach is a necessary measure just to keep up with demand. There are parts of the world where developers are the highest paid salary men of any occupation, just because demand is so high.