all bits considered data to information to knowledge

28Jul/140

Agile Methods for Disposable Software

I had a conversation the other day about agile software development with a friend of mine who is, by his own admission, a “real hardware engineer”. The focus was the Agile Manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

According to my friend, these statements are “either trivial, or naive, or plain wrong, or all of the above”.

NB: He also coined a hilarious ADHDDD term - Attention Deficit Hyperactivity Disorder (ADHD) Driven Development – and wrote a manifesto worth reading if only for its literary merits  🙂

Of course, as a certified Scrum Master, I beg to differ - but his attitude illustrates the point when a method (or its perception) can be taken ad absurdum. One of the common themes is that in the past the software was “designed to last” and Agile tell the developers “don’t think – code” … As any agile practitioner knows - nothing could be further from truth. Most of the COBOL written in 1960 is still running – but is it a good thing?  Borrowing from my friend's area of expertise, electronic tubes can work in stead of ASIC  - and ,arguably, with greater transparency (pun intended 🙂 ) – but would you really want to? Agile development does not preclude solid software architecture – quite opposite, it demands it! The fundamental quality attributes of the system are defined (and designed!) before a single line of code is written, and then – in close collaboration with the stakeholders - the rest of the requirements are being fleshed out.

We are living in the age of disposable software. This is a trade-off we've made to get the “latest and greatest” now - and cheap (preferably, free!).  Just take a look how things have progressed since 1980s - CPU, storage, RAM - all plummeted in price, and packaged software prices went through the roof...  (the Open Source movement only changes costs model – instead of “paying for software” one begins “paying for support and additional features”).

It might appear that we are rushing the development a la Netscape experiment of the 90s where a barely compiled program was foisted upon unsuspecting customers to debug…but it is a superficial analogy. We came a long way since those heady days.  We have a number of tools and frameworks at our disposal to shorten the development cycles – requirements gathering, build, testing, release – until we are getting to a nirvana of “continuous build” (and when we think that things cannot get any better we are ushered in a wondrous world of “continuous deployment”).

Is it better – or worse -  than a top-heavy process that takes time to spell out every requirement in a minute detail? The answer is, of course, it depends. A working software just-in-time for the market – albeit a buggy one – trumps comprehensive but obsolete one every time!

“For to him that is joined to all the living there is hope: for a living dog is better than a dead lion.”   Ecclesiastes 9:4

12Dec/110

IT debt, Inflated Expectations and Software Engineering

The IT debt is defined as the cost of clearing the backlog of maintenance that would be required to bring the corporate applications portfolio to a fully supported current release state.

It is estimated that the Global [IT Debt] to Be $500 Billion This Year, with Potential to Grow to $1 Trillion by 2015 (yes, all capitals, courtesy of Gartner).

Ah, the novel idea of functionally correct supportable code! There is a lot of poorly engineered software out there, and to some people it might come as revelation that a particular technology is largely irrelevant to the IT debt costs.

The CAST Report on Application Software Health sheds some light on "technical debt" or, as Gartner defines it - "IT debt", details. In absolute uncontested lead is...drums rolling... Java EE with average $5.42 of technical debt per line price tag (the costs of fixing the code). By comparison, COBOL has the lowest score at $1.26 per line of code; much maligned Visual Basic (.Net version excluded) fares much better - approximately the same as C.

Bill Curtis, chief scientist at Cast Software offers his explanation for the COBOL stellar performance - the code base has been around for 30+ years, and had better chance of being fixed during this time. As for Java, Bill said he can only offer a speculation  that "there are many people going into Java now that really don't have strong computer science backgrounds. We may just be seeing the fact that there is an awful lot of people writing code who aren't gurus in software engineering."

While I  agree with the diagnosis in principle, I'd like to point out that there were many more people "who aren't gurus in software engineering" coding in unpretentious Visual Basic  in its heyday (versions 3 through 6), and yet it came up with much better scores. With all the hype surrounding Java development in the late 1990s/beginning 2000 a lot of people led to believe that they are writing solid code just by virtue of coding in Java (on one occasion I was told that the system is "inherently scalable because it is written in Java"!). Call it inflated expectations: the built-in OOP, automatic memory management, structured error handling, byte-code portability and so on (add your favorite silver bullet here...) were expected to make up for the lack of software engineering savvy. Well', it did not - and the proof is in.

The same scenario played out with every technology out there. There is no substitute for sound engineering design and architecture - regardless of whatever technology that might be used to implement it.

 

P.S. It had occured to me that this is somewhat related to "Software Debt" concept explained in editorial blurb of the book by Chris Sterling -  "Managing Software Debt" - as follows:

"Shipping imperfect software is like going into debt. When you incur debt, the illusion of doing things faster can lead to exponential growth in the cost of maintaining software. Software debt takes five major forms: technical, quality, configuration management, design, and platform experience. In today’s rush to market, software debt is inevitable. And that’s okay—if you’re careful about the debt you incur, and if you quickly pay it back".

2May/114

Software Development Ecosystem

I became an instant convert into the concept of Software Factory back in 2007, and blogged about it in 2009 here

While I did not see much uptake in the organizations I came into contact with professionally, I still believe that it's only a timing issue, maybe with some minor tweaks added. One of such would be crafting more friendly and less mechanistic image. Hereby I propose new concept: Software Development Ecosystem (SDE).
I believe this definition better reflects complexities of the software development with subtle implications of  a living system, constantly evolving and self-regulating, while "Factory" carries somewhat negative overtones of a conveyor belt...

7Sep/100

A Collection of Well-Known Software Failures

A sobering read... a compilation on Lehigh University site:

A Collection of Well-Known Software Failures

26Dec/090

Profession vs. Technology

Whenever I hear a statement linking one’s profession to a specific technology (“a .Net programmer”, “a Java programmer”, “a Sharepoint developer”, “ a Ruby-on-Rails specialist”…) I cringe, and recall this story:  Profession by Isaac Asimov first published in 1957 (which I read for the first time in the late 1970s... )

This story I recommend as a required reading for every aspiring programmer, budding scientist or  high school student.

The story  is about a boy who aspires to be a Programmer, and discovers along the way that there is more to it than just a technology to master..The full text of the story (in pdf format) is available here;  for those allergic to science fiction here's a synopsis of the story in Wikipedia.

To summarize: a technology is too narrow to define a profession; maybe this is why technology certifications became virtually worthless. I do not want “Java Programmer” on my team;  I want a programmer who can use Java – or whatever technology we might be using at the moment to create a solution.

 Technologies come and go – no matter how hot they may seem today. What stays is refined body of knowledge, patterns and paradigms, rules to follow and rules to be broken... Nothing stays the same, all axioms have to be constantly re-evaluated. 

The quest is not to achive eternal bliss where everything is set once and for all, but to move forward with imperfect solutions optimal for that particular moment in time.. A catapult might have been the pinnacle of military technology innovation in it's time - and is a historical curiosity for several hundreds years now; but the lessons learned percolated into ballistic, structural engineering and rocket science...

11Dec/090

Unit Testing for Project Managers

This is a brief overview of the principles behind unit testing and test driven development. The target audience: project managers. 

    Test-Driven Development: what it is and isn’t, and why it will be good for you