Quite often when I meet with a client, they really don't understand what it takes to create an interactive web site. I'm not talking about things like design patterns or AJAX technology; I'm referring to the whole process, the fact that software is more than just lines of code. The sad thing is that many design companies work on such a small scale that they too think that software is just creating the system to spec, whatever that may be. This company also had that mentality for the first few years of our web development. While I understood that it took more, I was challenged with expressing that to the clients and other co-workers.
My first challenge was to convince my fellow co-workers that they are doing more than just coding when they are creating the systems for our clients. Sure, we had our share of straight up design projects that were nothing more than making a web site, but we moved away from doing those as often, as we excelled in our craft. When a programmer is in college, he/she learns about solving specific problems that have a clearly defined solution. This is often given by a professor, but some times the student comes up with his/her own. The challenge is to simply come up with a solution (usually trying to come up with the most efficient solution, which I often came up with [cough, cough, ego... lol]), using the techniques or algorithms discussed in the class. In school, the real problem is learning how to solve the problems and apply different techniques; whereas in the real world, we are not only concerned with the solution but also learning about what the problem is, coming up with estimates of cost and manpower, and researching technologies that you have not had to deal with yet, to name a few items. There is a whole laundry list of items that are typically forgotten about, especially when coming up with quotes. I stumbled across this list when reading Software Estimation: Demystifying the Black Art. The following are the things that we commonly failed to add into our time lines and quotes:
The list could go on further, but I believe I made my point. In my master degree studies at U of M - Dearborn (Go Blue!!), I further analyzed software engineering and came to the realization that on larger projects, writing software can be as little as 30% of the development time (growing exponentially smaller as team and project sizes increase).
It became important on our team to understand all of the actions that were necessary to build quality software, so that we can properly make time lines and quotes. A slippage in one project could have grave consequences in another (as deadlines could be missed, making for a stressful relationship with customers). I believe the best thing about the team here is that we all work together well and understand where each others strengths and weaknesses are. This further helps us to be real about time lines and what uncertainties exist in new projects. It also helps to to have a better appreciation for the work we each do, to ensure that the work is quoted fairly and that the tasks are not missing from the time line.
I have found that customers understand their domains very well, but do not have a real understanding of the domain that we work within. I can't tell you how many times I have had a client that wants a website that is very custom when it comes to interactivity, and to be done very cheaply (How many of you developers can attest to this?). This is no fault of them of course, but it further shows what I mean about clients not understanding what goes into developing interactive web sites. I think that the common person does not realize how much work actually goes into the sites that he/she uses on a daily basis.
The first thing that I do when talking to a client is try to get them to understand in their own perspective what is involved in what they are asking for. This will help to give them that "aha" moment that will help them to really look at what they are needing. Believe it or not, but more often than not, they really don't know what they need. They are just looking at what they see online and think that they need that too! It's like buying a new car, you want all of these features in the car until you see the final price. It is at that point where you start to remove the items that you don't really need and don't want to pay for. But, no matter how many features you remove, there is a base price (after all, you have to pay all of the engineers and staff that helped to create the car).It is at this point that we really need to explain to the client our process and why each of the steps are necessary. When selling a car, you have to explain to them that even though the car will stop on its own if it runs out of gas, it is required to have a breaking system. There are things in software development that a client may want to skip, it would actually be detrimental to his/her project to skip. For instance, requirements elicitation, testing, training, etc. While we usually aren't creating software that is life or death, there is a certain level of quality that must be maintained, and thus some amount of testing that must be done. Just like in buying a car, some things in software engineering are required.
The final thing that I have to try to help the client to understand is why requirements elicitation is necessary. I think that I can speak for all developers when I say that I wish the client could give me an exact list of all of the functionality that is needed, going even into the small details of how to do it (well, maybe not that small, but you get the point). Unfortunately, it is just not that easy. Many times clients will overlook things because they are so into his/her own domain that he/she considers it common knowledge. It is our job to talk to the client to really understand the problem(s) that he/she needs solved, the ins and outs of the domain, and the different nuances that are present in the organization/process. Once this is fully understood, the amount of uncertainty on our part is greatly removed. This helps us to give much more accurate quotes. Unlike a car, there is no conveyor belt of parts that simply get put in a file and "bolted" together to make the software. Each problem is different, requiring different elements to be programmed. I think that the book I mentioned early (Software Estimation: Demystifying the Black Art) explains this uncertainty the best. It has what it calls a cone of uncertainty. This cone represents the amount of uncertainty in the project as the project moves along. If a developer were to simply quote from an initial concept, there is about a range of 16 times from high to low estimates. After the requirements are complete, the range has moved down to about 2.25 times from high to low estimates. This really allows us to make an accurate quote, especially for the projects that are large and thus have a lot of uncertainty built into them. The real winner here is the client, as he/she has just saved a lot of money in development costs.
While I am not perfect (I know, a shock right lol), I believe that I have done a great job over the past few years to explain to my fellow co-workers and clients of what is really involved in creating software. I believe that we have a work environment and process down that really helps to create an atmosphere that is conducive to creating software at a high level of quality. We have established a good relationship with our clients that consists of a mutual level of respect. By educating them on what makes software quality, we have helped them to understand all of the support tasks that go along with the actual coding of the software. This did not come overnight though; the company culture had to first embrace this understanding so that we could convey it properly to the client. Spending a little money up front on things like requirements analysis and prototypes have actually saved our clients a ton of money because we would have had to build the uncertainty into our project quotes. Now, we can properly mitigate the risks to us and our clients, and in the process reduce the costs to the client as well. This has been done by helping the clients to realize that software is more than just lines of code...
