Agile Software Development

The term “agile” referring to software development processes is sort of a buzzword, but the intentions of those using the above word may in fact remain quite unclear. By this I mean that agile is sometimes used in its most general sense as “quick; nimble or acute”, whereas in other cases it points to a particular method within the agile development framework (which causes a good deal of confusion, as a matter of fact). Here I would like to look at agile development from what I would call its underlying perspective – agile methodology as a software development philosophy, a set of fundamental features determining the prospects cutting through each and every its elements, all the way from the targeted product to team members and their interaction patterns.
Looking at agile software development as a set of philosophical guidelines seem in fact the only possible way to go since it is prompted by its “umbrella term” nature (which, again, is the culprit of the above confusion). Extreme Programming, Scrum, DSDM, Feature Driven Development , and a number of other things all belong to the agile framework. This is a one-way equation: you switch the parts, and you get a completely warped idea of the whole agile concept. If you have previously dealt with, say, XP and the thing did not seem to work out that well for you, it would be unwise to shift your XP pair work frustration randomly at other things. It is a general-to-specific kind of relation.
While outlining the essence of agile software development, the easiest way to go is defining what is not agile, that is by contrasting it with waterfall development on the one hand and sets of chaotic code-and-fix procedures (or cowboy development, if you will) on the other. (Note: I do in fact realize that negative definitions are logically flawed. What I also realize, however, is that these give you an idea and provide certain valuable directions.) In this line, agile methods turn out to be a middle-of-the-road approach. Agile discounts both the rigidity of the former and the patchiness and anarchy of the latter.
So, what is the agile philosophy about anyway? First of all, agile approaches welcome flexibility and allow for changes at any stage of the development process. With agile development, work is done in shorter iterations (weeks rather than months). The focus is thus shifted off long-term planning, hence greater overall adaptability. Secondly, agile methodologies are highly collaborative, which implies that priority is given to face-to-face communication rather than to formalized written interactions. An agile environment is based on trust, motivation and a considerable degree of self-governance. Thirdly, agile development processes are undertaken in close cooperation with the customer and ensure considerable coherence between both the sides. To wrap it all up in a concise way, it is safe to say that the clue to agile software development processes is working software and its continuous delivery.
My final remark is going to touch upon one more crucial aspect, namely the applicability of agile philosophical maxims to a specific software development environment. Agile approaches need agile team members, which, in its own turn, implies having a mindset of a particular sort.

Entangled in Terminology

A glimpse into the somewhat enigmatic vocabulary of those creating software is enough to make your head swirl. Words keep popping up now and again – words that seem to ring a bell, but it is when you set the noble, if ambitious, linguistic goal of giving these terms a touch of terminological definiteness that you find yourself in a kind of no man’s land. How is software development different from software engineering, does the word programming serve as an umbrella term for both of those and, last but not least, how does computer science fit into the whole semantic system?
These are the questions that one is likely to find difficult to come to terms with when trying to muster the courage of plunging into the deep waters of IT. And, come to think of it, telling the difference between software development versus software engineering can turn out to be a good springboard for those who are just too obsessed with getting a definition for each and every word, which is exactly my case, those who need to deal with the IT guys and even those planning to get down to creating software (a roundabout term used here for the sake of convenience).
At this point, let me make it clear that in the present piece I’m sharing with you my idea of what might be the catch – an idea based on some observing and thematic reading, but still potentially subjective.
Now, there are a number of layers to investigate. On the one hand, to an average person out there, all the four terms might appear roughly synonymous, which in most cases can be just a piece of knowledge sufficient enough unless the average person needs to actually deal with these things. However, it could be noted here that people are mostly reluctant to expand their world outlooks, hence the fact that the terms programmer and software developer are mostly used interchangeably.
On the other hand, in the academic world, as well among those putting theories into practice, this kind of vagueness is not an option. Firstly, the computer science versus software engineering distinction seems to consist in distinguishing between theory and practice. Secondly, when defining software engineering one has to bear in mind the two components of the word: the engineering part implies that this particular term was at some point coined to emphasize an approach which treats the process of creating software just like any other engineering process, with all the inherent complexity, whereas the software part is there to point to the product’s underlying feature, i.e. its intangibility (in the definition by the Institute of Electrical and Electronics Engineers, software engineering is basically the application of engineering principles to creating software). Yet another aspect of the term can be traced from the programming versus software engineering distinction, i.e. the fact that programming is writing code, period, whereas software engineering incorporates management, coordination and design procedures, along with code-writing. And it is here that we arrive at the most challenging point: where does the borderline between software engineering and software development lie? It seems quite difficult to find any secure grounds to declare these as separate notions. However, the approach suggested by Prof. Gary Pollice in his article at http://www.ibm.com/developerworks/rational/library/dec05/pollice/index.html seems sensible enough. It boils down to the following: software development is the process of putting software engineering principles into practice. So here’s what I’ve settled for: software development is a less imposing, real-life word to denote the routine of organizing teamwork, creating specifications, writing code and, if you will, making software production more sustainable by relying on general practices commonly used in other engineering fields.