Digital Edition

SYS-CON.TV
Pointless Places, Boring Faces, and Useless Cases
I'm not against use cases per se; however, I like to keep them in their place as no more than an adjective to the verb "analyze"

Often in software I find myself preaching restraint to those who wish to move platforms for no apparent reason than to keep up with the IT fashion industry; however, even harder than the silver-bullet chasers is dealing with organizations where change is required, not only in a company's software stack, but throughout their entire IT department.

Recently I was involved in a customer project where the client had managed to bravely remain on a 30-year-old computing platform, while the IT fads of the '80s and '90s passed them by and were now embracing the new millennium by moving to a client/server architecture.

The first red flag with the project was that the client created a huge working group to size and spec up the new system, initially breaking off into different teams to assess various pieces of the problem. Much time was spent arguing about which technology to use, after which the IT manager, after a quick glance along his local bookstore shelf, unanimously chose for us and additionally decided that we should all embark on use case analysis.

I'm not against use cases per se; however, I like to keep them in their place as no more than an adjective to the verb "to analyze," the output of which is a set of functional requirements against which user scenarios can be tested.

The next two weeks were spent sitting in meetings with people who, clutching Use Case for Dummies, became alarmingly obsessed with whether a wireless connection was an actor or a role, or whether opening a door was a task or a scenario. The assembled architects lovingly raked up irrelevant anecdotes from their past, created fiefdoms and cliques, and meetings were dominated by aging personalities who seemingly loved nothing more than to hear the sound of their own voice while they argued irrelevant minutiae. The sane among us tried to re-orient the project toward a more agile methodology by focusing on a few simple scenarios that, through test-driven development, would be built and iterated over n times where the larger n becomes the more finessed the eventual deliverable turns out. Such heresy, to try to build the system without having formal specification design documents signed off in triplicate was shouted down by prima donnas who enjoyed warming their vocal cords all the more when senior management were present as they preached doom and gloom with stories of punched card stacks becoming dangerously mixed up on their way to the machine room.

As the weeks drew on I began to pity the IT manager who eventually fell back on the only rock he understood - a good old-fashioned waterfall design. He instructed us all to create 50 or so documents that would be sized, then summarized in a gospel-like spreadsheet, before being signed off by everyone present to create a project plan for presentation to the business units. By now, the senior managers, having spent a huge fortune and sizeable elapsed time on the redesign, concluded that their IT department was completely unable to get the job done and outsourced the project to a far flung ex-colony. I later learned from a colleague that they too failed to deliver anything of substance and the system rewrite was abandoned.

To do change well requires not only switching the technology platform, but altering how your software is designed, how it is built, how it is tested, and how it is delivered. There is little point in applying the design principles of yesteryear to implement systems in today's world where compilation is all but instant, unit tests are built into the development environment, and continuous feedback is how systems are refined. The end result can be perpetual meetings with bellicose and obstructive project personnel whose ulterior motive perhaps lies more in keeping the old, undocumented, and arcane systems alive where their inflated expertise benefits most, rather than embracing and adopting change.

About Joe Winchester
Joe Winchester, Editor-in-Chief of Java Developer's Journal, was formerly JDJ's longtime Desktop Technologies Editor and is a software developer working on development tools for IBM in Hursley, UK.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1



ADS BY GOOGLE
Subscribe to the World's Most Powerful Newsletters

ADS BY GOOGLE

"Akvelon is a software development company and we also provide consultancy services to folks who are...
More and more brands have jumped on the IoT bandwagon. We have an excess of wearables – activity tra...
Without lifecycle traceability and visibility across the tool chain, stakeholders from Planning-to-O...
The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it r...
The taxi industry never saw Uber coming. Startups are a threat to incumbents like never before, and ...
The next XaaS is CICDaaS. Why? Because CICD saves developers a huge amount of time. CD is an especia...
One of the biggest challenges with adopting a DevOps mentality is: new applications are easily adapt...
We are seeing a major migration of enterprises applications to the cloud. As cloud and business use ...
HyperConvergence came to market with the objective of being simple, flexible and to help drive down ...
Deep learning has been very successful in social sciences and specially areas where there is a lot o...
In his session at 21st Cloud Expo, James Henry, Co-CEO/CTO of Calgary Scientific Inc., introduced yo...
For better or worse, DevOps has gone mainstream. All doubt was removed when IBM and HP threw up thei...
Your homes and cars can be automated and self-serviced. Why can't your storage? From simply asking q...
Containers are rapidly finding their way into enterprise data centers, but change is difficult. How ...
I think DevOps is now a rambunctious teenager - it's starting to get a mind of its own, wanting to g...
"MobiDev is a software development company and we do complex, custom software development for everyb...
The “Digital Era” is forcing us to engage with new methods to build, operate and maintain applicatio...
Learn how to solve the problem of keeping files in sync between multiple Docker containers. In his ...
Creating replica copies to tolerate a certain number of failures is easy, but very expensive at clou...
"This week we're really focusing on scalability, asset preservation and how do you back up to the cl...