July 6, 2004, 12:31 a.m.

Future of Software Development?

Many times I find myself wondering about the future of the way we develop software currently. I guess if you ask different people their opinions you'll get just as many different views.

Back in the good old days we used to use punch cards to feed into the machine, from which the program is read and executed. Each time you want to execute a program, you have to load it using the punch cards again. Lateron came assembly language, where at least you could express yourself at the level of the CPU's opcodes, and save the programs for execution in an assembled, linked state called an executable application.

People used to build highly sophisticated systems using the archaic assembly language, under which operating systems, big parts of the original Windows NT kernel, etc. are examples.

However people soon started realizing that Assembly is way too time consuming, error prone and required a skillset that was extremely scarce, in order to productively and economically produce software. Therefore a higher level language called FORTRAN was invented, followed by Algol, CPL, Simula, PL/I, Logo, Pascal, C, C++, Java etc. The general trend in these languages seems to provide better productivity by easing the development of software systems. Take C++ as an example. It was built on top of C as an object oriented extension originally called C with Classes. One of the motivations was to enhance programmer productivity by providing a bit higher level of abstraction to the by then common procedural (algorithmic) approach.

Many languages today support object oriented techniques, such as Delphi, C++, Smalltalk, Java etc.

Some languages went a different route, called functional programming. One such language is Erlang. Other languages try to capture the essence of AOP (Aspect Oriented Programming). Neither one of the latter two are really in mainstream use today.

Whichever way, languages are only a fraction of the complete development effort. To support the developer in writing software, it was soon discovered that many tasks are repetitive, such as finding the length of a string, opening a file, connecting to a TCP/IP socket etc. So the concept of a library was born. A library contains a set of commonly used routines that developers just links in with their code, to have available all the wheels that had been previously invented without wasting time and effort trying to reinvent it. They come in many shapes and flavours, such as DLL's (Windows), .so (Unix), COM/COM+ (Windows), etc.

Nowadays libraries seem to be old fashioned for some strange reason. The hip words are "frameworks", "interceptors" etc. Frameworks are inversion of control systems, that provide all the core infrastructure in which you just fill in the gaps. This obviously has its advantages such as maintaining a common programming paradigm for all related software projects, less code to write, making use of good design principles etc.

With all this going on, I still truly believe that we are on the wrong track. Why? Because I believe it is more difficult these days to built a software based system than it was 10 years ago. I know that today's systems are much more sophisticated in many aspects, including features such as being distributed, scalable, internationally accessible, 24/7 uptime requirements etc. Nevertheless I believe it is possible to ease the process of software development significantly.

Take J2EE as an example. I have developed several systems using J2EE as architecture. Did it ease my development efforts? Nope. I don't think so. To develop a simple rebates calculator, it took 1 year from a team of 6 people, a budget of approximately $500,000.00, approximately 60,000 lines of code, 450 classes, 20 XML deployment descriptors and months of testing. I am pretty sure it would be possible to create such a system in at most 1 month, by 2 people on a budget of $30,000.00 if we had better supporting technologies around us.

Would JavaServer Faces help? EJB 3.0? AOP? J2SE 5.0? I doubt. They all just add complexity. Take Entity beans as an example. Many people believe it failed as it was too complex to work with, with bad performance to boot. So EJB 3.0 is supposed to simplify it. I am very sceptical whether JCP will succeed, since everything the past two decades revolved around increasing complexity.

Things are getting so complex, that with me spending the better part of 16 hours per day developing software using J2EE for the past two years, I still only know about 30-40% of J2EE. With that amount of complexity, how can anyone learn more technologies and techniques than just one (proprietary) technology? So gone are the days where we could say we know C, C++, Assembly, Pascal, Delphi, Java, Visual Basic etc.

Jumping back a bit into my discussion, why is web development still so complex and involving? Take a simple scenario - have a login screen, authenticate user (and allow him to change his password if it had expired), and allow him to add/edit/delete/view something. This requires at least 5 different JSP pages, lots of classes, DB tables, JBoss/WebSphere/Tomcat/etc set up and configured, Apache installed etc. It will take at least a day to start from scratch, get that up and running and tested. It is way too difficult! That task should have taken no more than 30 minutes. It is now more than a decade that we are using interactive web applications, yet there are no magical solution to this area of software development.

I am sincerely ashamed of the software community (me included). We should have came up with a better solution to writing software a long time ago - we need a paradigm shift soon