Software buzz words and development methodologies

Software buzz words and development methodologies

By Stewart Sims

The world of business tends to be intertwined with seemingly ambiguous phrases that refer to equally indeterminable methods of working. There are many conceptual software development techniques such as agile development, pair programming, and even ‘extreme programming’. I find it hard to contain prejudice against such an oxymoronic sounding phrase as the latter. Visions of programmers trying to debug their latest build of an application while snowboarding down alpine mountains make ‘extreme programming’ difficult to treat with total sincerity.

The benefit of good system design and software engineering cannot be denied. It is essential to save developers vast amounts of time they would otherwise spend constantly fixing and upgrading their software. In fact you could say the basic motivation and concept behind good design is simply common sense. This is not to be underestimated as those who are profoundly technically skilled do not necessarily have the slightest common sense about them. And if you put lots of technically able individuals in a room and tell them to build some software together, it would be inadvisable to have high expectations of the results.

That said people can and do build software without any methodology to follow. If you’re a programmer you probably remember a time where you didn’t utilise a design approach or draw a UML diagram to help you print ‘Hello, World’ on the screen. Even very complex software can work without extensive design and implementation methodologies.

One important part of this design problem is that people coming up with software designs do not always have complete technical knowledge of the platform that will be used to create the solution. This leads to those implementing the design, and therefore dealing with the technicalities, having to make decisions themselves that ultimately alter the outcome of the program. Unforeseen aspects of the software may completely change the structure of the program. If this happens, generally it is a ‘back to the drawing board’ situation, at which point you begin to wonder if design and implementation methodologies are worth using at all.

Abstraction (reducing problems to a simple model) is obviously key to developing useful software, but vagueness has little place in the world of software where you cannot just tell a computer roughly what you expect from it and hope for a result (yet!).

Reasons that should never justify existence of a buzz word or theoretical concept:

Deliberate control of information and making technology harder to understand

Job creation

Ability to charge more for a solution that adds no extra value than one that doesn’t use the buzz word concept

Reducing necessary time spent programming e.g. ignoring error handling or fast tracking and releasing a system before it is fully working [I think we know of a few corporations that do that!]

Agile development has become the marmite of the software world. Some believe it is essential to developing good software, and others think it is utter time wasting nonsense. Unfortunately as with many of the methodologies more removed from the actual technicalities of programming, agile development can mean many different things to different people. As such it’s hard to test and categorically say that it either is or isn’t useful. This could be taken as proof enough that it isn’t useful as otherwise there would by now be a more conclusive definition.

Extreme programming is a mire of unusual ideas about developing software, including ‘programming for today and not for tomorrow’ and testing not being a primary concern in software development. While it’s nice to see some ‘out there’ ideas relating to computer software which does tend to be a bland industry in some respects, frankly it is hard to give such ideas much merit considering they go against logical reasoning.

One buzz word I feel is worth taking note of is extensibility, simply because it is just a word and has a meaning relevant to software – making stuff flexible and expandable. If you design software with extensibility in mind, then you have achieved in my view one of the most important goals of good design. An extensible application is one that can work with as diverse a range of uses as possible. Therefore developing the application, dividing up the work and expanding it when necessary are easier to carry out in the long term.

I like to think of software engineering as a practical skill. Much like physical engineering it requires that you design the solution and split up the work in a relevant way. And like a physical skill it’s a skill that can only be developed through practice; there is no short-cut to becoming good at developing solutions. You learn and put into practice what you know and add to your knowledge when you encounter new problems. Experience is a valuable commodity in software development, and theory is only a small part of the puzzle.

There are many ideas out there about how to approach development. In my experience organisations all go about designing and creating software in different ways and some developers are more suited to certain methods than others. Therefore it is not up to an individual to come up with the design and implementation methodology of a company, as it should be something that is decided together and grown collaboratively, just as open source software develops in a natural way.

Whether a whole branch of software theory relating to ‘methodologies’ is necessary is debatable. A brief inspection of the word methodology in the dictionary reveals that it is in fact often misused, in cases where method would simply suffice. There are many ‘-ologies’ [from the greek suffix –logia] out there relating to fields of study that have provided great contributions to scientific discovery and human endeavour. The cynical amongst us might say in relation to software development, ‘methodology’ is not one of them.