What type of Software Shop Are You In?

I work at a software services company. We generally provide solutions to clients through software where the deliver mechanism is varied (Web, telephony, fax, so on). I am a Sr. Engineer and I am in charge of the Web Delivery mechanism, which we do a lot of. Over the past year I have written several "Framework" types of applicaitons and setups that can be easily reused or configured to provide clients with services.

We recently hired a new programmer as a mid level .net developer. He is in our Client Applications group, meeting client deliverables. We recently had discussions about software development that brought up several interesting points and concepts.

He feels that the software industry is really devided into two camps. He compared it to the Cold War. In one camp you have the Freedom Fighters, the guys who write custom software for each and every client. That way the client gets what they want, how they want it. In the other camp you have the communist, the guys who believe in software as a service where you build service based applications that are meant for a large crowd instead of a single client. He believes himself to be a Freedom Fighter.

His view is that each client need is different and therefore you should handle them uniquely and give them exactly what they want, each time. Then you can develop a relationship with the client and reap more of a subscription model out of it.

I guess that would make me a part of the Communist Party. I believe whole Heartedly in the Software as a Service model. Think about it; You write software once and everybody benefits from it. This makes both the software you sell more valuable (because you can resell it over and over again) and at the same time you can reduce the cost to your clients.

Let me compare it this way: Think of the Software Industry in the terms of the Food Service industry. The end result is the same, the clients get what they wanted. The delivery mechanism is the same; you have experts who design and workers who actually do the work and make the product.

A long time ago restaraunts did not exist. If someone wanted someone else, an expert, to prepare their food they had to hire the staff. If they wanted good food they had to hire a good chef. Each time they wanted a meal they had to sit down with the chef and explain to him what they wanted. Then the chef had to go back into his kitchen each time and figure out how to make it, then explain the process to his under chefs who would then chop, mix and bake, until the finished meal came out.

This is an iterative process. There isn't really a problem with this except that as a business model it doesn't lend itself well to the chef and his company unless he charges his clients a ton of money for each meal.

Then someone several hundred years ago had the idea that they could turn it around as food as a service concept. Thusly the restaraunt was born.

A chef could design the type of food he wanted to make. Then he could instruct his underlings on how to best prepare this food. And customers would come to his restarant because the chef served great food.

The thing that helps restaraunts make money is the fact that they run efficiently and they also have a predefined menu. The chef invents something, and it goes into the production process. Clients can come and order what the chef has invented. If they have a craving for fish, then they would go to a fish restaraunt. If they wanted beef, then the fish restaraunt is not the best place to order from.

Apply this concept to Software as a Service. You build a framework and basic services that run either over a downloadable executable or over the web. Your clients come to you because you have developed a solution to their particular problem. Now if you have a client who wants the Flounder but with butter sauce instead of the cream sauce that is one the menu, you charge an extra $2.00, but you can deliver it. He still gets his flounder because that's what he wanted, but now he can dip it into a great butter sauce too!

SAAS is the same. It's not Communism where I am going to develop a solution and you must fit into that solution without any complaints. It's ultimately flexable because I have already put my expertise in developing what I beleive is the best overall solution. If what I designed doesn't even meet your goal then don't use my service. If it does, but I can tweak it to better fit, then lets do that!

What type of shop are you in, Mr. Developer?

The State of Software Engineering

I am a software engineer. I design, code and connect systems. I think the software industry, more specifically Software Engineering, is in a sad state of disarray.

Take these two scenarios for example:

#1. How to build a new modem for a computer:
Step 1:
Conceptualize an idea. Describe everything feature wise you could ever want to support.
Step 2:
Design the system. An Electrical Engineer, or a team of Engineers, would sit down and draw several specs for the hardware.
Step 3:
Peer Review. You would usually get the people together who had the idea along with Engineers and go through a rigorous review process. No stone unturned. Modifications are made at this point.
Step 4:
Mockup. A workbench model is made of the device to make sure it fits the specified form factor and interfaces connect.
Step 5:
Prototype. This new model allows you to stick the device in a machine and test its interfaces. It doesn't work 100% but you are still in the proof of concept phase.
Step 6:
Working Model. This new model usually works, but has to be reviewed and reworked several times due to bugs.
Step 7:
QA Model. This new working model is what QA starts testing against. They test against industry standards and the design documentation.
Step 8:
Beta Testing. Some of said that end users are your best testers. They will use your equipment better and in different ways than a QA person would. This is usually where the ship date is set. Notice that it is often not a drop dead date.
Step 9:
Production. Now the specs are sent off to manufacturing before they hit the market. There will also be another round of manufacturing QA tests to make sure that manufacturing is building it right.

#2. How to build a Sales Lead Manager web application

Step 1:
Conceptualize. A client brings a problem to you or your team. Here is usually where a drop dead date is set. Notice that this often happens in the conceptualization stage and not further down the process.

Step 2:
Design. Usually 1-3 Software Engineers gather in a conference room for a few days to "white board" the idea and systems. The date has already been set, so you must "Trim the Fat" in order to meet your deadline.

Step 3:
Code. Code Code. Code.

Step 4:
Beta. Notice that I did not include QA? In most small to medium software organizations the QA process is either too small to mention or non-existent. Why? Because QA does not fall in line with the business push for the hard deadline.

Step 4.5:
Add in the additional 3 requirements that were not discussed in the conceptual stage, but that the CEO says are required now. Why didn't we think of these when he was describing it to us before?

Step 5:
Fix bugs. As many as you can. Some are tolerable, but you now have been working 20 hour days for three weeks now, so you don't really care. Cover up as many bugs from the end user as possible.

Step 6:
Roll out to production.

Step 6.1:
Oh crap. We missed several bugs introduced because of the feature creep. Rush to fix and re-roll.

Step 6.2: Oh crap. We missed several bugs introduced because of the feature creep. Rush to fix and re-roll.

Step 6.3: Oh crap. We missed several bugs introduced because of the feature creep. Rush to fix and re-roll.

Step 7:
Start designing the next release to fix the things you messed up in the first release.

See any problems here? There are no real standards for software development. Timeframes are not always relative to the scope of the project. Also, I can't think of a place I have been in the last 10 years of software design that scope creep has not happened. Even when my managers would issue a "Feature Freeze" he would always be overridden.

Hardware Engineering cost millions to make happen right. But the people who sell hardware know that's what it takes. The current Software Engineering landscape cost millions and then millions to fix, which could be prevented if it were treated like Hardware Engineering.

I think this causes the industry to get a black eye. I think it won't change unless industry leaders start treating Software Engineering as if it were Hardware Engineering. Hardware Engineering is so rigorous because they basically get one chance to get it right. But with Software Engineering we have this idea that we can always fix it later, that business has abused over the last decade or so.