After a few years venturing in this business, I slowly discovered the challenges of this business, and it might not seem promising as a long term career. When we are doing freelancing, we are actually running a business, and programming is just a fraction of our job scope. We have to do some PR and Marketing (word of mouth usually), find some work, collect business/system requirement (what need to be build), decide on the price and negotiate, develop, test, deploy and support. As you can see, the sales cycle is pretty long, and software development is a small fraction. So our skill as a good programmer only provides us 10-20% of advantage, and there is a lot more to pick up to be successful in this business.
Let looks further into the challenges of this business.
When you work in a big software/consulting house, you have corporate clients and nice thick system requirement documents are produced to cover your ass before you start programming. When you do freelancing, most of your clients is SMB/SME (small and medium-sized), and it seems almost impossible to create a complete specification before start of work.
When you meet up for system study or collect system specification, they usually tell you their requirement verbally, or if you are lucky, you have a few sheets of paper with some sketches and points. If you ask them to create the complete specification to cover every aspects of the system before you would start work, it would seems almost impossible for that to happen, and even when it does, the specification wouldn’t be very useful. Why?
- The customer have a rough idea on what they want, but they don’t know exactly what they want, and definitely don’t have the details for you (you have to help them make some decisions and suggestions)
- Somehow, full blown specification documentation is tiring and boring. Remember, this is not a large corporation, and people are not used to such procedure.
- Even if the guy is hardworking enough to create a full specification using his imagination and assumption, the specification wouldn’t be really accurate in reflecting the system actual needs and users’ expectation. At the initial stage, we can’t foresee a lot of things.
- Even if the full specification is created with good accuracy (does this ever happened?), it still will not cover you ass totally. A specification is still a specification, it can never be complete and it never will. The clients will eventually require something which might not be covered (or vaguely covered) by the specification, and he wouldn’t be very happy when you tell him you can’t do it because it is not covered in the specification (or you wanna increase the fees).
Basically, no one is gonna read a 100 pages specification, but people will take notice of a 5 pages simple specification in point forms with drawings, well labeled and categorized using color for the changes and request along the way.
Why not to create a 100 pages specification?
- No one will read it once it crossed the 10 pages hurdle
- It takes a lot of time to write that, and you are not paid for it (and the customer aren't going to write that for you, or pay you to write it)
- Does it matter if a requirement in in a specification or not? If the customer wants something, it needs to get in there. If something is good for the system or uers, you should put it in nevertheless. So what does the specification governed?
- It is impossible to cover all grounds, and changes will happen, so just accomodate it along the way (you can't anticipate everything before it starts)
- What need to be developed initially (original specification)
- What changes had been made along the way
- What additions had been made along the way
- List down components which are FOC, to show your goodwill effort
- List down components which require a lot of extra effort and chargeable, and justify (and the FOC section does helps)
So, how to fully cover my ass? I am afraid this is not possible. This is business, in fact business with SMB, and it is partially done on goodwill and trust basis. If you don’t trust them, or if they are very difficult to handle or being unreasonable, cut your losses and pull out, no matter how desperate you are (unless they are paying you BIG MONEY). Since the specification document can’t cover our ass, we need goodwill and certain level of trust and confidence. My mantra is if I satisfied their needs and do a reasonably good job, they will be more willing to pay my fees.
I am afraid specification document is just a small part of the initial stage. I’ll try to cover next areas such as
- Who you shouldn’t deal with
- How to decide on the price and negotiate
- Business Application Development
- Testing and Deployment
- Support is inevitable