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

The Good, The Bad and The Ugly Of Enterprise BI

When IT can't deliver, business users build their own applications focusing on agility, flexibility and reaction times.

The IT-Savvy 10%

IBM survey reveals best practices of IT leaders.

The Software-Defined Health Insurer: Radical But Realistic?

Can a tech startup digitally assemble the pieces of a comprehensive, employer-provided health plan?

Data Governance in Insurance Carriers

As the insurance industry moves into a more data-centric world, data governance becomes more critical for ensuring the data is consistent, reliable and usable for analysis.

Fear This

Just days before this Issue, which contains our security cover story, went to press, we got some interesting news: 1.2 billion unique usernames and passwords and 542 million email addresses were reportedly stolen from 420,000 websites, according to The New York Times. The websites ranged from Fortune 500 companies down to small online retailers.

Should You Back Up Enterprise Data to the Cloud?

Six questions that need to be asked before signing on with an outside service.