"Never Events" in Software Development

Without "Never Events"
a doctor is nothing more than a glorified butcher

There is a phrase in the medical profession known as a “never event.”  It is something that should never happen in a hospital or another medical setting.  People have been practicing medicine since Neolithic times.  We have only been writing software for about seventy years.  I think we can learn a few things from the field of medicine and I would like to discuss it on this week’s blog.

The term “never event” came from a medical paper from the National Quality Forum.  These are mistakes which should never happen in any medical setting.  Some examples of these never events are, people receiving the wrong type of blood during a transfusion, surgeons amputating the wrong limb, and discharging an infant to the wrong set of parents.  If something like this happens, the doctor is subject to profound liability, and a patient could die.  It is why they are called “never events.”

I thought about this, and I felt that those of us in the software business should have a series of “never events” for our profession.  If we are going to improve in the agile community, we need to have a set of standards and those standards should include things which should never happen.

Here is my list of never events for software development –

• Code which exists in production should never reside on individual’s computer; it should all reside in source control.
• The database administrator should never ignore system backups of data; data should be backed up regularly and before scripts are applied to the system.
• All code which performs business logic should have unit tests; this way you will understand where the system has changed and what the possible changes are.
• Network servers should receive regular patches and security upgrades; this will discourage hackers and avoid technical debt.
• A developer should never work longer than 10 hours; fatigue causes mistakes.
• Before checking in the code, it should be code reviewed by another developer; an extra set of eyes on the code prevents errors and helps to learn.

Those are my starting points for “never events” in software.  Look forward to what each of you thinks should be included on this list.

Until next time.

To Big to Succeed

People have a right to get upset about
Healthcare.gov

Like many people in the technology business, I am following the news of the roll out of the Healthcare.gov website with a mixture of horror and disbelief.  It is clear to me that the current occupant of the White House deserves some criticism for this roll out; however, I also think a huge dose of criticism should be leveled at CGI International who is doing the principle development.  In this blog, I want to discuss why consulting companies like CGI International are too big to succeed.

In the book “The Geek Gap,” Bill Pfleging and Minda Zetlin say that technical leaders and business leaders view the world on very different terms; the business leader is interested in control and influence while the technical leader wants to build things which work.  It is clear to me that CGI is more interested in influence and control than building working software.

During congressional hearings with representatives from CGI about the Healthcare.gov roll out, no project managers were discussing the problems encountered.  More aggravatingly the congressmen did not know which questions to ask.  So you had people who negotiate contracts attempting to justify why they should get paid to people who did not understand what they were paying for.  It was depressing.

What makes this even more frustrating is that there are great examples of technology and government working together.  Each year Intuit makes millions of dollars helping people do taxes.  They are able to wade through the income tax regulations and each year release software which helps people do their taxes.  Even if the law changes, they are able to update the software over the internet.  If Intuit can do this each year why can’t CGI?  This answer is that CGI, from the outside looking in, is the antithesis of an agile organization.

They value process and tools over individuals and interactions.  They are more concerned with obeying the letter of a contract that providing collaboration.  Finally, they don’t have working software but they have plenty of documentation of why they should be paid.  Of course, this does not matter because, CGI is highly successful and so deeply embedded into the project that firing them for a poor job would be foolish.  In essence, they are too big to fail.

I had a hunch something was wrong when I reached out to my local congressional representative by e-mail and phone offering to pitch in and author some web services.  The congressional office had a staffer contact me and assure me that everything was under control.  When I asked if there was a way to volunteer for the project, I was instructed to follow the federal procurement process.   As a two person technology start up, I decided that it was not worth the hassle to get further involved.  I am sure that other start-ups felt the same and that is why firms like CGI make money.  They provide lousy service but they understand government procurement so they do not need to excel at fulfilling contracts only closing them and getting paid.

Healthcare.gov could have been a smashing success out of the gate, but thanks to a bad procurement process and a firm like CGI, it began with a thud and is slowly being made functional.  I hope that the November 30th release is a huge success.  I did not go into business to become CGI; I went into business to build things which work and solve problems.  I hope this is an object lesson to our elected leaders being able to win a contract does not mean that they can actually do the work.

Until next time.

Software is Never Free

Just like the Merchant of Venice
we all need our pound of flesh.

Being a software entrepreneur is a difficult business to be involved with.  I spend much of my time writing software and then the remainder selling it to others.  It is difficult and I could not think of anything else I would rather be doing.  Still I do have one big challenge and it is the same challenge all types of creative people are facing.  It appears that in this internet world of abundance they do not have to pay for books, music, or software.  This week I would like to explain why software is not free.  Someone has to pay. 

I believe that this notion that software should be free was spawned from the Linux movement during the Dot.Com boom days.  Countless pixels have been spent expressing the view that software should be free and that copy writes for things like books, movies, and software were quaint notions from the pre-internet days.  I think it was professionally and culturally poisonous for the software industry.  Please let me explain.  

Software, music and books are the one of the few things we have not figured out how to automate.  The creative process necessary to build them are labor intensive and imprecise.  These processes are also prone to spectacular failure.  This is why when you check the CHAOS report it is clear why many of the software projects are challenged or failing.  It is hard to match the expectations of the people paying for the software to the abilities of the people writing that software. 

Along came the Linux movement with the religious fanaticism of the Opus Dei.  Linux was a version of the Unix software program which was developed by AT&T during its monopoly period of the 1950's and 1960's.  What made it unique is that it was freely distributed over the internet via download.   This meant that instead of paying a license for an operating system for a computer it was free.  Companies sprang up to support this ecosystem of Unix and provide a means to cash in on all the companies who didn't want to pay for software but didn't know how to use it.  So the tradeoff for a company was no cost for software but huge fees for labor to maintain and customize the software.   This spawned a system of software which is used today in the corporate world; Oracle Databases, Java Development, and PHP for web development.

I suspect that the Linux movement had to happen because companies like IBM and Microsoft made a very good living off charging people to use their product.  To software developers who tend to be an iconoclastic lot having free and open software was a nirvana of sorts.  Upgrades were based on the needs of the community and weren't subject to a corporate project manager.  Finally, the open source Linux movement emphasized the technical ability of the developer to make changes to core systems and improve the product.  Thus, free software seemed to be the best of all worlds; developers judged on merit, free products which respond to real needs, and something that was technologically elegant. 

Of course, something was missing.  Since these free products we constructed by engineers for engineers, for non-technical people they were impossible to use.  MS-DOS from Microsoft abandoned command line prompts for the windows interface for a reason.   They wanted more people to use their systems.  The Linux movement still used the command line.  In addition, major manufacturers did not create Linux personal computers so they had to be created by hobbyists and Linux fans who have been affectionately labeled a "priesthood" because of the difficult process of developing technical competence and the religious devotion they have to the Linux world view.  Finally, no one had time to write Linux software.  This is because many of the people who worked with Linux were busy updating the system and working in the corporate sector keeping systems working; in other words, with no killer application that would force people to use Linux people in the consumer realm did not use it. 

Flash forward to today, now an entire generation has grown up with free software.  Piracy is rampant in music and on-line books and when I hand a contract to a client they look at me like I am crazy.  "You expect me to pay that much," they say and I grit my teeth and say yes.  Just like my customers, I have bills to pay and mouths to feed.  They charge for their services so why should they be shocked and surprised when I charge for mine.  I think this has been my biggest frustration as an entrepreneur.   I am charging for my services and many people think I should be giving it away for free. 

I think I have a pretty good service to offer.  I have an inventory management system which works over the cloud and can be accessed via a browser, tablet, or mobile phone.  I am in the process of completing a contact management system for the insurance industry which will make it easier for people to trace sales and leads on-line.  It also works with the cloud via a browser, tablet, or mobile phone.  I am even leveraging QR codes for advertising and contact management for small businesses. 

It is an exciting way to make a living but it requires people to realize that software is not free.   It requires blood, sweat and tears to create.  I have invested most of my life into software.  You should invest a little money into to product I sell you.

Until next time.

Why Software Development Fails.

Software development does not have to be
a train wreck.

The greatest thing about the internet is that you are exposed to the wit and wisdom of countless professionals.  When you gather together a bunch of these people we want to talk about what we do for a living.  It is just a natural extension of our identity.  Firefighters talk about firefighting, cops talk about police work, and gather together a bunch of elementary school teachers and the topic of teaching will always come up.

Last week I was exposed to a great blog article from Headspring consulting.  In it, they talk about the latest report from the Standish group.  Software developers are getting better at delivering products on time and on budget, but the success rates still resemble batting averages from baseball instead of a mature industry.  This week I want to discuss this blog and why it is so damn hard to write software. 
The present success rate for software projects is still below 50%.  This means if you are a business owner you have a less than 50% chance of a project coming in on time and on budget.   I have to agree with blog author Jeffrey Palermo, this is unacceptable.  This is why I suspect that many business owners do not want to spend money or time on software and technology because they know that the investment is risky.

I have a few theories why software is so risky.

First, software is the only technology product which is not automated.  Computer, smart phones, and mice are all manufactured on factory assembly lines.  Software is created by a bunch of engineers by hand.  This process is similar to writing a novel but it is done by committee and under often unrealistic deadlines.  This hand crafting of software means that there are no standardized parts.  So communicating with a database can be done a myriad of ways instead of one standard fashion. 

Next technology environments are heterogeneous.  It is common for a large company to have servers which run UNIX, desktop computers which run windows and staffs which have Android phones.  This means that software developers spend a great deal of time fitting square pegs into round holes.  The data on your UNIX servers needs to get on your sales forces smart phones.  It is up to your software developer to figure that out.

Third, software engineering is a craft that needs to be learned on the job.  When you hire a welder, you know that if he is hired from a union that he has spent countless hours training both in the classroom and mentored on the job.  The same holds true when you hire a plumber.  These trades have long apprenticeships where the skills to succeed on the job are taught by more skilled artisans.  Sadly, no such system exists for software engineers.  Entry level developers can be self-taught or they can be graduates from prestigious programs.  This means that no two developers are going to have the same base knowledge.

Next, there are so many different languages and design patterns for software development and no one agrees which is best.  If you want to start a fight among software developers mention that Java is a superior language to C#.  Developers are very territorial about their skills and if they are confronted with individuals who don't see design patterns and languages the same way there is going to be conflict and non-cooperation. 

Finally, many of the people who lead software teams do not have any knowledge of how software works.  If you are going into surgery you want the lead surgeon to be a doctor just like the other surgeons.  In technology, you often don't have a software engineer leading the project.  You have a manager with project management or sales experience.  This means they do not understand the challenges of the people who are actually doing the work.  It also means that they do not have the skills to help a team when it becomes "stuck" or faces unrealistic combinations of resources, time, and money. 

This is one of the reasons why I founded E₃ systems.  I wanted to do software development properly.  Since we have launched the company we have gone through two major revisions to our Sully Business Intelligence Platform.   We do an upgrade on average every three weeks and each time a potential customer has asked for a feature we have delivered it in the next release.  We are pretty proud of that record and if you would like to know more you can contact us here.

So you can take your chances developing your own software and have a less than 50% chance of success or you can hire a team that does software development the way it is supposed to be done.  I hope you give us a call. 

Until next time.