Eric is a DZone MVB and is not an employee of DZone and has posted 17 posts at DZone. You can read more from them at their website. View Full User Profile

Programming in the Small

  • submit to reddit

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. 


Published at DZone with permission of Eric Daugherty, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Chad Hahn replied on Thu, 2010/03/11 - 9:20am

"Successful applications today are about the user experience."  When has this NOT been the case?  It has always been about the user experience and what they want.  The market determines who wins and who loses.  I don't think that's any reason to cry in your beer because you don't get to write all your software from scratch any more (and honestly, I question those who would want to).  There is still lots and lots of interesting software to be written and plenty of problems to be solved.  To think otherwise just puts you in the "640K ought to be enough for anybody" crowd.


Erin Garlock replied on Thu, 2010/03/11 - 10:45am

Not all applications are pretty pictures GUI eye-candy.  I work in the high-volume banking world and most of the application development is about writing backend/backoffice code from scratch. 

It's great when there is a complete spec and an associated library to handle message formats, messaging, and the like but many times we're the ones creating the standards.  It isn't exactly rocket science, or in many cases computer science, but there are certainly challenges that can't yet be addressed by gluing some libraries together and writing a small amount of code. 

The real difference here is business apps versus consumer apps.  Business apps tend to do more communicating with other processes and computers.  Consumer apps do most of their communicating with the human.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.