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. 

Bastard Spawn of a Development Tool.

Not bad for a bastard.

One of the basic truisms of technology is that any solid professional relearns their job every eighteen months. Based on that reckoning I have had to retrain myself nine times during my career. It is not pretty and it can be mighty humbling. I complain about the process on a regular basis but I also understand it has given me a modicum of independence and a living wage. This constant struggle of competence is just a fact of life in this business.

I am going through a similar transition right now as I learn how to run my own business and master this funny technology known as MVC. In this blog, I want to talk about MVC and how I am starting to slowly like this bastard child of PHP and ASP classic.

MVC stands for Model View Controller and it is touted as different means of building web application in the ASP.NET framework. MVC partisans claim that this approach better supports test-driven development, total control over HTML generated on the page and divides complexity of the application into meaningful chunks.

When confronted with MVC3 in August 2011, I felt a wave of despair because it looked like I would have to unlearn everything I have ever done with web development over my entire career. It also did not help that my manager used to say things like, "..of course you don't know any better you are a web forms guy."

Instead of a page with code behind as is typical in web forms, I had a controller which handled the http behavior, a view which had no server controls , and models which are nothing more than classes which are passed between the controller and view. Even the markup on the view seemed alien looking like old ASP classic.

Matters were made worse by MVC3's steep learning curve. Unlike web forms which allow a gradual learning process from entry level developer to master. MVC demanded you code a particular way right away. It felt like learning to fly in an F-15 fighter jet instead of a single prop Cessna. It was maddening being given tasks in MVC which would have taken me hours with web forms taking days and weeks.

Over the last six months I have gone from completely helpless with MVC3 to an entry level developer. I still feel that the training books out in the market need to be better to help web forms developers make the transition. I also feel that Microsoft and its partners could provide more classroom style training to get developers up to speed. If I ever get a chance, I might write a book on the subject.

Complaints aside, I have learned to like MVC. Thanks to MVC3 and JQuery mobile, it is easy to write mobile application. They do not even need to download an application. Just fire up the smart phone web browser and you are in business. I also like MVC3's ability to finely control HTML so that CSS and JQuery behave in a cleaner fashion. The security model of MVC 3 is exactly the same as web forms which allows you to use the same security for a web forms application as a phone application. Finally, MVC has forced me to be a better object oriented developer and improved my LINQ skills.

I may be just a "web forms developer," but I understand where MVC fits in the pantheon of web development. Barrowing from Greek mythology, the hero Perseus was the bastard son of Zeus and Danae. Somehow in spite of his questionable upbringing, Perseus turned out OK. I expect similar things from MVC.

Until next time.