Custom Projects
Everyone seems to accept that software development is very hard to do, so I thought I would share some of my insight having just completed a rather large project in a short time frame for a client.
1. While Software Engineering teaches us that there is a trade off between price, quality and time, time cannot be reduced without sacrificing quality.
Firstly, there is only so much time in a day. Regardless of how much money you throw at it, the sun will not stay up for longer.
Secondly, when time lines are tight, important processes and steps get sacrificed. When teams have to be productive, they will (of course) focus on the more productive tasks. This means people focus on coding, the actual work required to get the product completed. Tasks that these team members would normally perform such as contributing to specification documents, QA processes and planning of system architecture are reduced in importance as a result.
Another critical step that is removed is testing. It is very difficult, if not impossible to test on an unfinished product. Usually by the time the coders are sweeping off the last bits of functionality, there is only a small rushed amount of time to get some testing done. User testing can often lead to things like identifying major missing pieces of functionality that can really put a spanner in the works.
This all adds up to a lower quality product. While it may work, it will most likely not work well, and be of a buggier than a product that has had suitable time allocated to scoping, planning and testing.
2. Working longer hours does not improve throughput.
I can understand with short projects that this could work. Two or three days of long hours to get the work done before a deadline is not overly problematic, as long as there is adequate rest time to return your body to its natural state.
When you start to push the hours consistently, you start to run into problems. Fatigue causes mistakes. Big ones as well as small ones. These mistakes will more often than not outweigh the minor gain in throughput you will get by working long hours. This does not serve anyone, so try and keep things balanced.
3. Versioning systems are a godsend.
Install them, learn them, use them. They make collaboration so much easier. I will never work on a large project without one again.
4. Expect and account for Scope Creep.
We all know about scope creep. It is one of the main reasons projects go over time, over budget and generally fail. While there are techniques for avoiding it and dealing with it (specifications, change control processes, etc) know that it simply cannot be avoided and include an estimate in budgeting.
No matter how good a specification is, it will never document the entire product. If it does, I dare say it would have been a larger investment than the cost of actually producing the software in the first place.
5. For every staff member added to a project, there is significant overhead introduced.
This might sound obvious but it is more of a problem than people realise. Two programmers will have to collaborate to share tasks, agree on coding conventions, discuss approaches and explain themselves.
This has to be recognised and accounted for.
6. The larger the client, the more administrative overhead you will have to deal with.
The more stakeholders you have in a system, the more opinions you will have in the mix, the more questions you will have to answer, the more times you will have to repeat yourself and the more time you will spend sending emails.
People like to have everyone happy. People also suck at communicating emotions, or the importance they place on things. This means clients will try to accommodate their entire team’s feedback into the product. This can sometimes lead to you being asked to do the impossible, the difficult and even the plain stupid, regardless of the cost.
For example: someone might voice the opinion that the size of a rotating flash image is a little too large and should be reduced by half a centimetre (25px). Others would not disagree; some might even make murmurs along the same lines. Before they know it, they have agreed to perform the change. They go to the developers and request it. The developer says “well, it’s a pretty involved change as we have to re-do all of the vector animation, I estimate $300.00″ and because there was consensus in the group and no one can put a figure against how badly they want the change, it goes ahead. Completely useless, expensive change that makes very little difference to the final product. Of course, the team will make positive noises about the improvement as no one wants to admit they just wasted $300.00 for no reason.
I call this process “death by committee”. A little term I came up with while watching the last few scenes of “The Life of Brian”.
To help address this, try to establish a single contact in the organisation who is responsible for collating and requesting work.
7. Projects must have an end date and there must be a celebration.
Deadlines are important. As much as we hate them, we need them. Without a deadline, you can’t see the light at the end of the tunnel. There is no glimmer of hope on the horizon, just the same damn project for the foreseeable future.
Projects need to end with a sigh of relief, regardless of what ongoing support or loose ends you might need to tie up. You need to say “it’s over” and be able to move your primary focus elsewhere. Without this, things will simply continue down the same old path.
8. Burnout is real.
Look for it, notice it and deal with it. It’s much easier said than done.
Large projects with accelerated timelines will take their toll. Stress is the main contributor of burnout, so dealing with stress is the first step to preventing burnout.
Down time is essential, you are not superman and bottling things up inside is asking for trouble.
9. Stress is contagious
Be mindful of the others around you. If your boss is stressed, it is likely that you will instinctively become stressed as well.
Humans are very tuned into each other’s emotions. The delivery or phrasing of a sentence is usually more than enough information to know that something is not quite right. Others (especially those in a team) will pick up on this. If you are acting concerned, people will feel that there is likely to be something they should be concerned about and will also be concerned. If you don’t believe that a system is good, others will also believe that it is no good and pride will die.
Try and be positive, even if you are screaming on the inside. This gets harder the longer you are working on something.
Don’t let the system consume you. At the end of the day, it is just a job and not the sole reason for your existence.
So, I hope this is valuable to someone.
And yes, my project has been a moderate success. Around 88,000 lines of code in less than 3 months and an 80 page spec doc to boot. Came in mostly on time, mostly in budget and the client is mostly happy.
Thank god.