Blog

Codifying Software Development Can Lead to Disaster

Jason DeBoever
Insurance Experts' Forum, June 5, 2012

As organizations mature, the natural tendency is to document and codify software-development processes, and then provide a system of oversight to ensure they’re followed.

This is a good thing. No one would trust software written by a team that codes from the hip, and worse, deploys from the hip. Even lean software practitioners like me follow a well-defined process for software development.

Insurers, vendors and consultants use methodologies and processes to deliver software solutions to a market, whether internal or external. The process that any development project follows must cover some basics—for instance, the need to know explicitly where requirements will come from, how source control will be handled, and the need for testing by someone other than a developer. And of course, accountability; everybody involved needs to know who has the authority to say "it ships."

So after that, everything else is gravy? Well, far from it. There are still dozens of other important decisions to make about your process.

The temptation is to find the products and methodology solutions that promise to be the ever-popular “answer to all your problems.” "Hey, we've seen these problems before," promoters of various products and methodologies say before adding, “We have all the answers.”

People love to hear that the answers have already been found, and all these impressive people/conferences/articles agree that scrum/kanban/RUP/etc. represent the absolute best approach for any project.

The devil is always in the details, and hard questions must be asked: Are your teams well suited to pair programming, unit-test code coverage, fine-grained tasks and burn-down charts that a particular methodological approach might call for? Do you need functional specification documents or non-functional requirements?

The best answer doesn't come out of any single methodology, nor can it ever. It requires careful consideration of your staff. For instance, some developers like clear short-term goals they can claim success on; others want involved challenges that have some R&D element to them.

It also requires consideration of your customer's appetite for risk, cost, time and quality. It requires understanding whether your customer knows what they want, or whether they are just taking a first stab.

Putting It in Practice

So, we’re supposed to have a process but aren't supposed to mindlessly follow a recipe. Where does that leave us?

There are many best practices, which are easily identified because they are common across many methodologies and process approaches. Things like repeatable deployments, frequent user feedback and bug/enhancement tracking tools are almost always key components of a successful project.

Overreliance on formal methodologies often leads initiatives down a dead-end path where methodologies and processes are used and performed for their own sakes. Following a ritual will likely mean that the project will take far longer and costs more than it should have—and the software often still doesn’t do the job.

This should never be the case. The answers to the real-world challenges are almost never prepackaged and shrink-wrapped. Instead, always take a step back to take a look at and assess your own environment and needs—before you find out that your development process is broken.

Jason DeBoever is a senior architect with X by 2, a consulting firm in Farmington Hills, Mich., specializing in enterprise and application architecture for the insurance industry.

Readers are encouraged to respond to Jason using the “Add Your Comments” box below. He can also be reached at jdeboever@xby2.com.

This blog was exclusively written for Insurance Networking News. It may not be reposted or reused without permission from Insurance Networking News.

The opinions of bloggers on www.insurancenetworking.com do not necessarily reflect those of Insurance Networking News.

Comments (1)

Thanks for this thoughtful piece, Jason. It's great to hear a balanced approach to getting software projects done.

With the excessive hyping of Agile, the software industry has obscured the need for adaptive management of projects, taking into account the style and structure of each organization.

Having consulted for a mid-sized insurer in the San Francisco Bay Area, I observed an attempt to use "agile" processes to overcome major obstructions that could not be overcome by any Agile methodology. Instead, they had to fix each organizational and management problem, one by one, before faster and more accurate implementation could be obtained.

The bottom line is that there is still a need for experienced consultants whenever IT projects are failing.

Posted by: John Levy http://bit.ly/yKMCQt | June 8, 2012 3:51 PM

Report this Comment

Add Your Comments...

Already Registered?

If you have already registered to Insurance Networking News, please use the form below to login. When completed you will immeditely be directed to post a comment.

Forgot your password?

Not Registered?

You must be registered to post a comment. Click here to register.

Blog Archive

Don’t Wrap Your Organization Too Tight With Metrics

Metrics provide a picture of how business is going, and systems are performing. But do they provide the right picture?

Insurance: The Original Shared Economy

Insurers should look to revisit the roots of the insurance process.

The Seven Flavors of Virtualization

There is no one single form of virtualization rather, different parts of the IT infrastructure require different approaches.

Can New Technology Turn Older Cars into Safer Cars?

Unless you have the means and motivation to buy a new car every year, your newest car is quickly about to become an older car.

What if Someone Kickstarted an Insurance Company

Our industry is evolving and implementing new innovations, particularly focusing on the customer experience, including the web and mobile.

The Transformative CIO

Today's technology leaders are expanding well beyond their traditional role.