It’s the User » Historically speaking, the most profound change in the way we build software today is in how we care for the user

Publicado el por

http://drdobbs.com/architecture-and-design/232300570?cid=DDJ_nl_upd_2012-01-17_h&elq=7707e2f3236b4763bb6370eae9a3c2ae

Historically speaking, the most profound change in the way we build software today is in how we care for the user.

Perhaps because Dr. Dobb’s has been around since 1975, I frequently get letters from readers to the effect that they’ve been programming 20|30|40 years and a current practice mentioned in an article is no different than what was being done in programming decades ago. I rarely publish these curmudgeonly dismissals of current practice because, in my view, they are almost always significant distortions of a superficial similarity. The most common attack I hear is that some Agile practice is nothing new, «we were doing that in the 1980s.» That is almost always a fallacy. I hesitate only over the qualifier «always.»

Programmers who worked in the 1980s know that even the most basic best practices and tools needed for Agile did not exist then. For example, most sites had no formal version control system. Version control was generally done by saving files using names containing dates, so you could go back to an earlier version on the basis of date (rather than what was changed). Once you were assured the current code more or less worked, you were encouraged to get rid of the date-marked intermediate versions. There was no pervasive ability to attribute code changes to a specific person because there was no way to track who had done what. Likewise, build management was not viewed as a discipline unto itself and there were few tools that enabled you to recreate an earlier version of a product because few shops kept track of what versions of components went into what release.

The concept of short sprints also did not exist at most sites. Actually, sprints of any kind were unknown. And modern practices such as continuous integration did not come into the common experience of developers until some twenty years later.

But perhaps the most telling difference between then and now was the view of the user. Up through the beginning of this century, the general IT view of the user was a sort of indulgent condescension. Users were seen as a necessary evil. They were certainly not people you’d encourage to participate in regular product reviews and provide constant feedback.

Without the practices of regular user feedback, short development cycles, continuous integration, and tools like version control, there was no ability to respond quickly to changing requirements. Consequently, there was no agility. Things that look like or smell like agility in such an environment are merely coincidental in appearance. However, even as far back as 1968, it was becoming clear to the folks who had eyes to see that the aforementioned model (despite its persistence as a valid approach for decades more) was not workable and in need of change. Here are some quotations on point taken from a report from a 1968 NATO software engineering conference (note that the full report is a 136-page PDF that loads slowly.)

«We are starting gradually, and building up. My motto is ‘do something small, useful, now.’ Large systems must evolve, and cannot be produced all at one time. You must have an initial small core system that works really well.»

And later technology approaches were anticipated: «System testing should be automated as well. A collection of executable programs should be produced and maintained to exercise all parts of the system…As an output of a test validation run, each test should list the modules it has exercised, and as well, should list the interfaces and tables it has tested. It is important to document success, as well as failure.»

The report itself communicates a gathering dissatisfaction with the waterfall model of that era, which was highly focused on requirements gathering, design, and implementation as separate and distinct stages. There was also great concern that as program size grew, this approach would become increasingly unmanageable. The concern was primarily expressed in terms of cost and schedule, rather than anything else. Satisfying the user was considered a given via the requirements stage. So there was no strong feeling about the need for a methodology that enabled changes to occur during the development phase. The closest anyone comes (in my scan of the document) is this statement: «Users are interested in systems requirements and buy systems in that way. But that implies that they are able to say what they want. Most of the users aren’t able to. We should have feedback from users early in the design process.» Not exactly a full embrace, is it?

We can see that the idea of constant user involvement had not yet emerged even among leading adopters. And there lies the crucial factor. Today, we operate profoundly differently, not just because we have better technology (although certainly that’s a major contributor) and better development practices, but because we have a user-centered approach to development. In that sense, modern practices are different, in fact fundamentally different, from those of previous generations.

— Andrew Binstock
Editor in Chief
alb@drdobbs.com
Twitter: platypusguy

http://drdobbs.com/architecture-and-design/232300570?cid=DDJ_nl_upd_2012-01-17_h&elq=7707e2f3236b4763bb6370eae9a3c2ae