Saturday, December 15, 2012

Why Efficient Software Development?


Software Complexity

Grady Booch (one of the co-authors of the Unified Modeling Language), in his book “Object Oriented Design”, describes in the very first chapter why the world is complex by nature (with all its events and its properties) and consequently the software has to be complex since it is a representation of reality. However, a point that Booch neglects to specify is that such complexity can be very well abstracted so that end users don’t have to deal with it. In other words, Booch makes reference to the human capability of abstraction just to explain it as a brain process that is modeled in the Object Oriented programming paradigm; but does not relate it to his first chapter of complexity.
In short: Despite reality is complex by nature, and Software is a model of the reality, Software can be simplified by building a foundation framework from which new models can be created; that hides most complexity and allows users of the higher layers to focus only on the semantics of the problem they intend to solve.

The Software Construction Cycle

In the past, minimum Software Cycles included:
  • Analysis
  • Design
  • Coding
  • Testing
  • Implementing
Nowadays, this cycle has become more and more complex, with additional stages that are required today due to more demanding sophistication. Steps like Use Cases writing (for refining Analysis of Requirements), Quality Assurance, Defect Management, Unit testing, Integration Testing and several others have been added (or expanded) to the major ones above mentioned.
But, do we really need all of those? This question should remind us about a published quote by a Microsoft Executive in its early days “We are the company with the largest technical support team”. A week later, Lotus Corporation, then a major competitor of Microsoft, published the following quote “In Lotus our Technical Team is small… thanks to the fact that our software is better and does not fail as that of companies with large technical support teams”; with clear reference to previous Microsoft’s quote.
Microsoft developed its so well known .NET Framework, which is a collection of patched components on top of its old technologies, rather than redoing it from scratch. As well as Microsoft, many other companies have monsterswhich it’s better not to awaken if we don’t want to deal with their fury.
Despite the nice advertising published in most developers’ magazines about Microsoft Visual Studio, the reality is that, for the simplest application, a lot of ridiculous steps need to happen, versus simply opening a text editor (with nice keyword coloring, of course) and enter a simple “PRINT ‘HELLO WORLD’”.

How Does It Work?

Framework

The first step toward efficient software development consists in creating a sufficiently robust, yet simply (cleverly) programmed framework.
A framework that will allow to dynamically generate any live component or object with which the user will interact. Modern technologies such as XML and the dramatic lowering of memory and hard disk space cost allows to put a lot of properties into objects that can be dynamically created on the fly.

Dynamic Typing

Purists of “abstract data type” concepts strongly reject the generation of dynamic objects, arguing that it completely defeats the purpose of defining a class. However, pragmatism has to be taken in consideration, as well as the ability to exploit existing memory and hard disk when it comes to dynamic generation. On top of that, a robust, intelligent management of data conversions is key when there is a need to put together a set of properties to be exposed to the user. This is one of the major arguments against dynamic typing and languages like JavaScript.
Yes, a very strong typing is needed in languages that require tons of code, as the simplest typing mismatch can cause catastrophic results. However, when a software component is created in a smart way, optimizing its code pieces and minimizing redundancy of code, dynamic typing lets programmers manipulate coding in faster and easier ways; and if it comes with smaller code pieces, the possible “mismatches” can be easily caught and fixed.
Ultimately, even languages with static early binding typing require mechanisms that allow combining information (such as conversion or cast functions); which is what dynamic typing languages (as JavaScript) end up doing. At the end of the day, every single data type is simply a set of bytes (or, better said, a set of data items) that have a special behavior and together mean something to the user. Not only that, very frequently, operations between data types is needed (like concatenating a string to numbers and datetime fields, or adding or subtracting hours, days, weeks, months between dates and types, and so on).


Reusability

Another important concept of Object Oriented Programming that has been overseen in the latest development tools is the reusability, which is supposed to minimize the need of programming the same set of functions or properties multiple times without needing to repeat them. In other words, create a “black box” that allows forgetting about deeper details and lets programmers focus on new features.
Unfortunately, that is a fallacy since, in reality, tools like Visual Studio and other “powerful RADs” don’t take advantage of reusability appropriately, and instead insert tons of repeated and redundant code in the different pieces that “programmers” put in their software projects. There are certain levels of reusability, but the concept as it was originally conceived in OOP is not really taking place.
Of course, a lot of that problem has to do with programmers inability (that’s why the word was quoted in the previous paragraph) to think cleverly, and they are happy dragging and dropping objects from a tool bar, later spending endless hours programming the cosmetics of the application. In short, all those visual tools have became a mechanism to reproduce crap at higher rates than in the past; further complicating systems, then causing softwareprojects to be more expensive and require larger development teams, larger project management teams and larger testing phases as well as bigger defect tracking systems. 

No comments:

Post a Comment