Programming in the Small
Programming in the Small
Join the DZone community and get the full member experience.Join For Free
Take 60 minutes to understand the Power of the Actor Model with "Designing Reactive Systems: The Role Of Actors In Distributed Architecture". Brought to you in partnership with Lightbend.
I believe that successful application development today is about 'tweaks and sub-features', not major functionality. But my thought process for this post was kicked off by an interesting post by Mike Taylor: 'Whatever happened to programming?' Mike laments the evolution of programming. He is nostalgic for the day when writing a program was about creating something from scratch, instead of assembling the various pieces.
I think his assessment of the transition is fairly accurate. The number of frameworks and libraries in projects today far exceeds the number used in projects 5, 10, or 20 years ago. This is especially true in the Java world, where build tools like Maven gained traction because they handled the dependency management. And now, a non-trivial Java project can easily incorporate 100 or more jar files, while a trivial 'boiler plate' web application can easily have 20 jars.
In many ways this is frustrating. It has also given rise to what I call the cut and paste programmer. You can actually achieve reasonably impressive results simply by searching for the right libraries, and them assembling them together but cutting and pasting example code found via Google.
From a business perspective, these are all good things. The level of skill required to produce results is lower, and the speed of development has greatly increased. We are standing on a very tall foundation.
This also means that the major functionality of many applications is provided mostly by libraries and frameworks. The heavy lifting parts are not really heavy anymore. I think Jeff Atwood hits this nail on the head when he stated on a Stack Overflow podcast episode that the major features of Stack Overflow themselves are fairly trivial. The real value is that it is a collection of many small features and tweaks that make the overall system successful (I can't find the reference, so I apologize if I paraphrased incorrectly). I think this point is right on. Most major 'features' are trivial to implement today using the rich set of libraries that exist. Building a website that has questions an answers like stack overflow is trivial. Making it successful is hard. And the difference is all in the fine print.
Jeff discussed at some length the time they spent with the syntax parser (markdown) and instructions on the 'ask a question' page. Small changes to how the information is displayed and highlighted are much more important then the major feature of saving the question to a database and displaying it.
Successful applications today are about the user experience. There are very few applications that are truly innovative themselves and could not be replicated by gluing together a set of frameworks.
Real innovation today is in the small. This is also why I believe that the rise of Appliance Computing is here, and that Write Once Run Anywhere languages are inferior to native client applications. It is the difference between a iPhone web application and a native app. They both have the same features, but the experience can be very different. In the end, the real value is the small efficiencies in the application, not the large features.
Opinions expressed by DZone contributors are their own.