Managing Software Projects – The Way We Set It Up Is How It Ends Up
Managing Software Projects – A Software Engineers Perspective.
Contrary to popular belief, many aspects of a software project could be proactively controlled and managed by an ordinary software engineer to make his life easier. Instead of whining about frequent requirement changes, looming deadlines ..etc, there are many things you can do to help yourself retire with enough hair left. The “Managing Software Projects” series is an attempt at exploring these aspects.
It amazes me to see how little attention is paid to this simple truth when a software project is undertaken. There is a reason why it’s said “you reap what you sow”. More often than not the success of a software project (for that matter many things in life) depends on how well you have laid the foundation. But It seems far too many think that software projects are immune from simple realities in life. You don’t need to have elaborate plans or lengthy kick off meetings, but reasonable time and effort needs to be spent on getting the basics right. While none of us have the power to foresee every obstacle that might crop up during the project, there are many aspects that are within our control. And more often than not, these aspects are not given their due recognition, hence taken for granted !
The Way We Set It Up Is How It Ends Up.
What can be managed should be managed right from the start by following the proper process. We all know we need to test, use coding standards, provide documentation, do code reviews, follow process..etc, but how often do we think about these aspects right at the beginning of the project? These are things that we can control to a reasonable extent, but if not paid enough attention could spiral out of control and eat up enough cycles to cause major disruptions in your project later on.
- How many projects use a continuous build system right from the start? In the first couple of days or so you may not even have enough tests to run, but ensuring that at any given moment the code is compilable and tests are passing will set the tone for the project right at the beginning.
- We all think we could write documentation when we have enough functionality, but we soon find out that we have quite a bit to write with not enough time. Ditto for code review & coding standards.
- Same goes for writing tests too! By the time we decide to write the tests in earnest, we have done quite a bit of coding. All that time saved by not writing tests and a lot more is now wasted doing damage control.
- Using a bug tracking system right from the get go is better than using sticky notes:)
- How often do we slap in a quick ant file/make file ..etc to get it going soon, thinking we can improve it later as the projects gets more complex. Anybody who had gone through the pain of tinkering with the build system when the project is in full swing knows what I am talking about. Spending some time upfront designing a more robust build system would save you loads of time and frustration down the line.
- During the initial setup period, how often do teams discuss about the internal release process, branching policies, how to handle hotfixes, bug fixes for existing releases etc. If these points are discussed in earnest right at the start, then perhaps you could put in place structure that would accommodate them more easily vs having to bend over backwards at a latter stage of a project when we really need to do it.
Simply put, following proper process right at the start will determine how successfully your project ends.
This Applies Even When Your Are Doing A Proof-Of-Concept (And here’s why)
I have seen many proof-of-concepts being done without using any version control, without adhering to coding standards, using a bug tracking system or writing any sort of tests. The justification being it’s only a proof-of-concept, and we could do it properly when we get to the real thing. But how many times have we seen the proof-of-concept being used almost as it is as the initial code when the real project starts?
Now all of a sudden you have a lump of code, that is not reviewed, documented, tested or version controlled properly. Since no bug tracking was used, all the time spent in testing the POC is now wasted. While nobody cares about the POC being stable and forgive you readily when the system crashes several times during the demo, the same allowance is not given when you deliver the real system. But scarily enough the same unstable code is now being used as the base for the real system. Now is the time you lament about not following proper procedures during the POC development.
Ideally a POC should be what it is – a POC and nothing more. The real system should be started from scratch. But the problem is, we don’t live in an ideal world!
So if your organization has a history of turning POCs into real systems in double time, then follow process right from the start to avoid a stroke or a heart attack.
The Only Thing That Does Not Change, Is Change Itself. So Plan For It At The Beginning!
Changes are going to happen! Either the customer or the marketing dept or both will change their mind. These changes will happen for a variety of reasons and more often than not they will need to be accommodated. We cannot have an architecture that will withstand all the numerous RFE’s. We cannot plan for everything. But we could still have a plan for dealing with these changes! Having one right at the beginning will save you a load of trouble. You may need this kind of planing at different levels.
- Most organizations have a process for dealing with changes and RFE’s. But you may need to have a project specific criteria as well. What might work for one project may not work for another, so the corporate guidelines may be inadequate in covering all scenarios. Working that out right at the beginning and getting approval from all concerned parties may reduce a load of pain at the end.
- While you cannot architect for every conceivable change, we could still try to identify areas in the system that can potentially change. Not only this is useful in scheduling, it is also important in the architecture stage as you could try to isolate change as much as you can. Even though you have no control or visibility into how a particular feature might eventually pan out, you still maybe able to isolate it enough to minimize the impact the changes could cause in your system.Identifying areas that could change at the beginning and setting up your architecture in such a way will ensure how well you deal with inevitable changes.
- Similarly testing strategies should also be planned with changes in mind. Having this discussion right at the beginning rather than later will no doubt contribute positively towards the success of the project
Related to this topic is discussions about resourcing, requirements planning etc. These aspects are critical in properly setting up a project. However the above piece is written more from a software engineers perspective. In some ways the software engineer has very little influence (ex resourcing, requirements planning..) in determining the way a project is setup and in other ways quite a bit is within their sphere of control (ex. the aspects mentioned above). The idea is to maximize what you could manage/control and plan for what you cannot.