I was intrigued that the lecturer would spend this amount of
the course time on the subject and even go as far as to give an assignment
through which we were expected to demonstrate our understanding of these software development terms.
But that is not where we are going to camp out for today, what
I really want to get across was how this very simple principle of
cohesion-and-coupling was to be the gravity that dropped the penny for me once
I entered the working world. You see I now believe that, reason than the
lecturer had spent that much time in ensuring that we understand this principle
was that one needed to work quite hard at applying this in “real-world”
software development. Eventually you develop a feel for it, but there was no
set formula for determining compliance to such important principles.
So just a few years into the working world and this is what
I have made out. Much Like that first lecture, developing and delivering software
solutions for organisations is a soft-science as opposed to a hard science. In
as much as there has been a great deal of literature over the past two decades
discussing how organisations are increasingly needing to search for technology
managers that understand not only the engineering but also the business and
financial principles that apply.
Imagine that you are working as an independent contractor to
a retail store and you have been tasked with ensuring that their latest
in-house POS goes through the SDLC and onto the check-out isles of its couple
dozen chain stores. You have been given very strict deadlines as the executive
are driving to have the systems rolled out in time for the silly-season.
Now, you know that you’re engineering abilities are quite
sound and you are feeling quite confident that you can deliver a robust
solution. But how are you going to ensure that you get continuous feedback from
the project sponsor. How are you going to ensure that your modules are
“acceptance” tested by the user and the business community? For any developer
that is in touch with current trends the answer might seem obvious. You will
very likely have to apply some kind of “agile methodology”. And herewith lays
my argument.
The methodology selected has a great bearing on when and what
you are able to deliver, so much so that in today’s world where many solutions
are available for developers on the WWW and today’s developers are much less
concerned about memory and network constraints as the developers two decades
ago. If we were to draw a graph where x is time and y is the level of
significance for “critical success factors”. I argue that we would see a trend
where the hard science that is engineering ability has gradually began to drop
over time and is slowly approaching its terminal. On the other hand the
soft-science that is methodology and technique has begun to increase in
significance very rapidly. In conclusion we are living in an age where software
companies are forced to act under a soft-science. In my next piece I will look
more into the implications of moving from the hard world to the soft world.
