At the days when the first computer was designed in 1940s, the software development business was born. It has been evolving fast and furiously ever since that.

Talking of software development, we, developers, will immediately think of programming languages like C++ or Java or their ancestors like FORTRAN or COBOL. Programming with those languages, or “coding”, is at the center of our software development career.

However, several new software development trends started to threaten the crown position of “coding” in the kingdom of Software Development.



Take a deep look at Software and Codes


A piece of Software is a set of instructions that can be deployed on a hardware platform to carry out certain tasks. Usually, it’s broken into hierarchical layers. The lower layer is closer to the hardware and tends to be more generic while the upper layer is more application specific.

“Codes” are a bunch of instructions written in high level languages like C++, Java or C#. They need to be compiled and deployed to the platform before the hardware can utilize them.

We can see codes just one form of software. It’s hardly the only form for sure.

Configuration Programming

There is another type of artifacts we deal with frequently, the Configurations. While the codes are stable logics and have to be developed before deployment, the configurations are flexible logics that can be easily changed at deployment time or even at runtime.

Configurations can take many forms. XML files or database tables are two most popular ways.

We used to do a lot of “coding” or programming and do little configurations. But, recently, things seem reversed. Not only have we moved more and more logics into configurations, but also we have started to consider “configurations” part of programming.

Spring’s Injection of Control is a good example. The relationship between business logic objects are embedded in the Spring configuration files. So are Struts and many other popular software frameworks.

The line between codes and configurations seems blurred. Business logics can be easily swapped between codes (“hard code”) and configurations. The trade off is between stability vs. flexibility and maintainability vs. traceability.

Customization Packaged Software


Configuration programming came to the extreme in packaged software like SAP or Oracle 11i.

The only thing necessary to make the packaged software work for a specific scenario (client) is to make some changes in the configurations, a process dubbed as “customization”.

That’s something very different than the traditional “coding”. But, as we move towards a more specialized software development industry, customizing and assembling packaged software modules may be the best way to develop software now and in the future.

Visual Programming

Another hit comes from the promise, “Anybody can become programmer.” This sales pitch has long been popular in the Software Development Tools industry. The idea is that the tools vendor will manage all the underline hard wiring and provide the developers a very simple user interface to define the business logics.

Microsoft has been a pioneer on that one. Their Visual Basic turned the programming into drawing diagrams and writing minimum amount of codes. Obviously, .Net is going through the same path for development, only further.

The major J2EE vendors, like IBM WebSphere and WebLogic, are also catching up this trend. Each developed a sophisticate IDE that grant the developers the capability of “quickly constructing new process-based applications using drag-and-drop development tools to visually coordinate the interactions”.

In the hot arena of “Business Process Management” and “SOA”, we also see this trend. Complex business processed are designed in “drawings” in the GUI and then output to BPEL language.

Look Into Future

Thirty years later, we may experience a totally different type of software development, just like what we are doing now is unimaginable for the programmers working with the punch cards decades ago.

We will spend less and less time coding and more and more time in thinking through the business processes and business logics. Once we draw the logics or write the formula on paper (real or electrical one), our job is done. The rest are all automated by third party tools or packaged software.

At that time, we may all bear the title of Business Analyst rather than Software Developers. Personally, I have no problem with that.