Is PaaS our Silver Bullet?
Developing software is difficult. We may have the best developers in the world, the most agile development processes, and the best coding tools available, and it will continue to be difficult. This is so because of software’s nature, because of its essence. The only way of not having problems developing software is by not developing it! Could it be that modern PaaS technologies are the silver bullet we need to kill the software development werewolf?
Begegnung im Haus (Werwolf von Neuses) via Wikimedia Commons
In his classic work, The Mythical Man Month, Fred Brooks tells us why it is impossible to find a “silver bullet” for software development (Brooks 1995). Software developers for decades have been seeking for that magical silver bullet needed to make software easier to develop, yet developing software is still very hard! His argument on why will we not find such a bullet and why developing software will always be hard lies in the distinction between software’s accidental and essential complexity.
Software’s accidental complexity refers to the problems in coding the software. That is, problems in making sure the software provides the functionalities it is supposed to provide, that it performs well, and developing it as fast as we can. As technology progresses, we’ve been able to make coding easier: Writing in assembly language was much easier than punching cards, 2GL and 3GL removed the complexity in writing assembly code, and today plenty drag-and-drop GUI’s have taken a fair share of the code writing out of the equation.
As Kevin McEntee pointed out in his key note at Cloud Connect a few weeks ago, the accidental complexity has been generational. Today’s complexity may lie more in the “running” the software than in the “coding”. As Kevin notes, today we’re concerned with running out of space, obsolete equipment, power & cooling, among other issues. I’m sure that the IT industry will work its way out and solve these issues in the near future, particularly with the advent of cloud computing.
Nonetheless, we still have software’s essential complexity, which Brooks argues is the root source of our problems and relates to the inherent properties of software: system complexity, conformity, changeability, and invisibility. There’s little we can do about these.
About system complexity, if we define a “complex system” as “one made up of a large number of parts that have many interactions” (Simon, p. 183-184), then software is complex by definition. Moreover, given software’s hierarchical nature (i.e. routines are made of sub-routines, object classes have sub-classes, web services call other web services), it is easy for software to rapidly evolve into complex systems: “complex systems will evolve from simple systems much more rapidly if there are stable intermediate forms” (Simon, p. 196). The growth also increases software’s span (its number of sub-systems, p. 187), which increases the number of necessary linkages between parts that must be taken care of. Software is complex, and it is hard to keep track of all its moving parts. We could claim that modularity reduces complexity, but that’s just a tradeoff: we decrease complexity at the module level and increase it at the integrated system level as there are more pieces to be integrated.
Conformity refers to the fact that software applications to not exist in isolation. Software is meant to have interfaces (i.e., GUIs or APIs) to entities outside of its domain, and there’s little a developer of a particular software app can do to control them. Again, there’s no way of changing this; it’s part of software’s essence. Changeability is closely related to conformity and it refers to the fact that software is never a static element because its requirements are never static. Just as how the world around a software application changes, so must the software application adapt. This is particularly true when trying to satisfy end-users’ requirements, who in many cases do not even know what they want and change their requirements on every release. We cannot fix and prevent change in the world around our apps. Finally, invisibility refers to the intangible nature of software. We cannot “see” nor “touch” software. Not even the most sophisticated modeling techniques can adequately represent all the moving parts of a software application. “The reality of software is not inherently embedded in space” (Brooks 1995).
Since the only way of avoiding software’s essential complexity is by not developing it, then, we may think that buying packaged software or subscribing to a SaaS offering is a great solution. Nonetheless, all what we’re doing here is passing the headaches to someone else. The software provider must still deal with all the above mentioned issues. Moreover, we, as users, become the source of many of the provider’s challenges.
We I initially learned about PaaS I though it was a great step in solving the difficulties of software development. After all, the selling pitch of Force.com, Heroku, GAE and other PaaS offerings is that they make the developers’ life a lot simpler by abstracting the infrastructure management part of the story. Nonetheless, this is nothing more than a cool solution to infrastructure-related accidental complexity. The developer must still deal with the essential complexity. So, could there be some other way of bypassing the software development process? Not entirely, but we’re getting closer.
At Cloud Connect, in part thanks to a discussion with Krishnan Subramanian, I learned about OrangeScape, a “visual PaaS” solution (that’s how they call it) that allows users themselves to code and deploy their own software apps. What’s the benefit of this? Let’s look again at the essential characteristics of software. The underlying IT stack (e.g., a LAMP stack and its corresponding infrastructure) is still very complex, yet the user, now developer too, does not care about it. The user only cares about the complexity of his/her requirements. Also, who better than the end-user to decide how must a GUI be? Conformity on that side is taken care off; though we must still integrate with other systems. The impact of changeability is also mitigated. Instead of having a developer gathering and trying to satisfy changing end-user requirements, why not have the end-user satisfy his/her own requirements? We must still consider the changeability of the technical context, but this one would be less fuzzy than user-driven changeability. Finally, OrangeScape’s nice and familiar (it looks just like Excel) GUI allows end-users to visualize their own software processes, reducing the impact of software’s invisibility. This is like Scratch for business applications!
It is worth making a pause here to note that this is not the first time that software applications empower end-users to work on their own. Reporting tools (i.e. Crystal Reports) and other business intelligence applications have been around for long and have reduced the need of a developer to generate a report based on some set of data. These tools allow the user, who is the one who best understands what he/she wants to see in a report, to develop the report on his/her own. What is new in OrangeScape’s solution is that now users are implementing the business logic part of software. They build the apps that generate the data, not just look at it.
I will not claim here that modern PaaS offerings are the silver bullet. The inherent essential properties of software are still there. Getting the end-user closer to the development process is only half of the problem and we must not forget that someone had to develop the PaaS platform in the first place. Nonetheless, it is still nice to know we’re solving a part of the problem. Our quest for the silver bullet continues.
Brooks, Frederick P. (1995) The Mythical Man Month: Essays on Software Engineering. Addison-Wesley Professional; Anniversary edition. Chapters 16-17. Simon, Herbert A. (1996) The Sciences of the Artificial. MIT Press; 3rd Edition. Chapters 7-8.