The art of developing software...

In developing software, the resulting code needs to obey a number of structured rules in order to guarantee future maintenance and enhancements. Furthermore, new software needs to be modular and obey established open standards to guarantee interoperability with the work of other developers. Finally, the graphical user interface (GUI) of developed applications needs to obey established standards imposed by current best practices and operating systems. For instance, developing software for the Apple OSX is very strictly constrained by the OS itself. This makes OSX application development extremely efficient. That is the reason that most PowerPC packages were converted in record time into native apps for the Intel OSX version; Apple just provided the necessary SDKs with lots of libraries, covering the vast majority of functions used in any given application package.

The above implies that, these days, developing good code is the result of a highly disciplined effort. From an architectural point of view most new applications are structured along three tiers, the UI, the Logic and the Data. To this end new applications are developed as highly modularized and are using heavily the established standard protocols depending under which framework they are being coded (for instance, under Windows, new developed applications use extensively the so-called web services protocols, whereas with Open Source and Java, similar objectives are achieved with EJBs, etc...).

Manual code development methods, as opposed to CASE (Computer Aided Software Engineering), where code is automatically generated based on a database (encyclopedia) of cross validated specifications, face a serious problem with development discipline. Developers jump too early into coding, especially with approaches like Agile Development and Extreme Programming; they don't properly plan the application design and testing and, even under the current modern development frameworks, they still end-up creating uncommon and complex (spaghetti) code as they used to do with unstructured Cobol in the 70ies. This code, often poorly documented, is extremely difficult to maintain in terms of bug-fixing and functional enhancements. On top of this, such code suffers heavily from regression problems.The only strategy to improve developer productivity and quality of their code is thru what is known as 'enforced discipline'. This has been attempted in the last 30 years via CASE technology. We are currently operating in the third wave of that initiative, albeit this time we seem to have moved backwards, away from classic CASE into rather 4GL and 3GL, non-withstanding the availability of frameworks, standards, protocols, libraries, and SDKs.

From the above description it becomes obvious that modern IT managers, facing the challenge of their current applications legacy that has to be maintained and gradually replaced by a new legacy, are very sensitive to and receptive of commercial offerings that seem to resolve part or the whole of their development issues. This also explains the success of SAP that, despite the high implementation cost and its generally primitive code and methods by which this was created, offers the sense of a safety net against the challenges of future functionality and ability to scale. Sort of 'never get fired for selecting IBM in the 70ies and 80ies' thing. By supporting the vast majority of enterprise applications, SAP took away many of the headaches of the community of contemporary CIO’s...

__________________________________________________________________

PS. I found this 'excerpt' in a white paper that I wrote some time ago to guide some people into evaluating a young company that came up with a wonder product used to develop commercial web sites. I don't believe in wonders and miracles, especially in software development. It's all about management discipline and applying the protocols and best practices. Years ago the software Industry killed CASE, almost in its cradle, as the latter promised to steal away programmer flexibility and freedom of choice (the 'artistic' aspect of 'programming' per many, their element of creativity... let me laugh). Consequently, we ended up in the software development pre-history, run by bunches of amateur 'pros', albeit with modern tools. I am curious to see what the distant future will eventually bring about.