The AMS project was quite an involved project. It consisted of various steps and as it was also a high priority and critical project, it did not make any sense to leave it in the hands of one developer. The team that was put together for this project were each experts in their fields and offered years of experience to the project. Being part of this team also taught me the importance of team work and how even a mission critical and behind schedule project can be brought back on track easily and quickly with the right structures in place.
My project manager and development lead during the project taught me some very good rules of thumb to apply during any development project. These are rules I always knew about but was rarely able to properly implement during project development and with this project I am proud to say I learnt these quickly and it made my work a lot easier then before.
Three Important Questions
The first lesson was the first three questions to ask during any project. These questions are important as they define the role you are going to play in the project.
Who is the project manager for this project ?
It is always important to know who the project manager (PM) for the project will be for various reasons. The main one being that this is the person you turn to for your time management, deadlines and to ensure that the pressure is not on you, the developer. When you are struggling with a particular piece of code, inform the PM. When you are getting two hundred phone calls from various people regarding the status of the project, refer them to the PM. When you need to have extra resources assigned - Refer to the PM. As a developer your job is not to crisis manage, interact with the stakeholders of a project, or even to provide deadlines for modules. These are all the tasks of the PM. Therefore it's imperative that you have a good, solid project manager behind the project to ensure that all these tasks are filled by everyone except you.
Where is the documentation for this project ?
Functional and Technical Specifications, no matter how small the project, is absolutely key. If you don't have a piece of paper saying what you are meant to code, you will be coding for weeks on end and never finish. Always get a specification document from your PM and always enquire as too who is meant to write the specification. Also remember that code comments is not specification documents, rather a reference to the specification of how it was implemented. Always get everything in writing, and that way you can do your job better and smarter, rather then end up working through the night to meet a deadline due to missing the target every day.
What cost centre does this go to ?
Strange question ? Not really, often developers are led down a long and winding road of trail and error and the client is billed or even worse the Development department is left with the financial burden. Any good development house or company's main focus is always making money, and as a developer you must ensure that you are not costing more then the project, and in the end proving yourself redundant.
Which Cap to Wear
All of us as developers have various caps to wear. These caps are different aspects of our jobs, but the lesson is learning to only wear one cap at a time. Never try and wear both at the same time because it will count against you in the long run.
Project Management Cap
Your role when wearing this cap is to manage the project time line, risks and people. At this stage you are not a developer, nor writing technical documents. Your skills are required to evaluate time-lines, manage users, check on resource availability and ensure that everything required for the projects, during and after has been completed including the planning, development and testing phases. The roll-out phase is a separate project that also needs to be managed including the management of the training. When you wear your Project Management Cap don't be a developer, don't think in code, and make sure you meet everyone of the clients needs.
Technical Writer Cap
Your role when wearing this cap is to write the Scope, Functional and Technical documentation for this project. Your not thinking in code, your designing the architectures, meeting the needs of the project and determining the time-line. You need to ensure that every aspect of the project is documented or being documented. Ensure that you know what the project entails, what the risks are, and also what will be needed to actually develop the project.
Developer Cap
Your role when wearing this cap is the simplest of all. Implement and write the code as per the technical specifications within the allocated time-line. That's it. Nothing more. Stick to Buttons & Boxes and this goal will be easily achieved. At this point you don't even do complete testing, since that is what the testing phase is for. You will ensure that your code works and that it achieves the requirement set by the documentation. Don't get fancy, get the code out and into testing and ensure above all that you comment your code as best possible.
Testing Cap
Your role when wearing this cap is to be the end user. Break the system. Use it in an environment setup up similar to the actual roll-out environment and make sure that it's stable, and try and do what a normal user does, even better, give it to a normal user to use, and see what the results are. Changes and bugs are reported via a bug tracking mechanism to you. Don't fix code while testing, just test. Document all the bugs and changes and then send it to the PM for a project plan, documentation and new time-line.
Buttons and Boxes
Stick to working buttons and boxes. Make sure the code does exactly what it is meant to do without getting fancy. Don't write lines of code to automatically fill a box, let the user click a button to fill a box with information. If the end user wants a automatically filling box they will ask for it during testing and implementation. Make sure you keep your code simple and clean, and only if truly required use fancy ways of loading screens, using threads, making web pages. Amazingly simple is always the easiest, and a 100% easier to bug fix later then the 200 lines of code written to let something run in a background thread.
Yeah right, all of this is not possible during a project ? Is it ? Well, after working on AMS with an experienced team I have learnt that everything I mention here is not only possible, but actually works. So, the next time a project comes my way, I will be reading this entry again... and following it step by step.
