Reflection is an important process in the journey of learning. This post tries to capture the lessons learned from leading a project. This project is not a large one and not extremely complicated, but it encompasses all the typical elements of a software projects, for example, project planning, design, implementation, testing, task assignment, collaborating with other teams like QA, public perception, etc.
The lessons are categorized by the various aspects of a software project.
This phase is all about thinking, analyzing and validations. It requires exercising a large number of neurons in your brain. Strong analytical and thinking on your feet skills are useful tools to have to be effective.
Like most of other tasks, the task of translating conceptual ideas into something more concrete will require some trial and error thinking, exploring options, validating new ideas and be open to other perspectives. One must be open to new ideas and not rush into judgment. Use cases are the guiding lights as well as your best friends.
This is probably the most challenging phase. Coming out of this phase may reveal that one needs to be humble and accepting the fact that there are so many more things that one doesn’t know.
Working with new technologies is always fun and challenging at the same time. The important thing is to make sure they can satisfy your requirements. Resist the urge to use a piece of new technology just for the sake of fun or seeing it as another bullet point on your resume.
Technologies suppose to help you becoming more productive and having better sleep at night. Therefore using familiar technologies or mature ones is a safer bet.
Building Phase and Pounding the key board
This is all about following a blue print that was laid out in the previous steps with a grain of salt. When the rubber meets the road, sometimes it requires revisiting the initial thinking and coming with another alternative solution.
The other important elements are avoiding taking shortcuts and about being consistency. Short cuts will come back and haunt you during the QA cycle or worse after it is in production. Typically an application has a set of similar structures and functionalities. It is important to be consistent in the implementation of these similar parts.
Consider unit testing as your friend. Test cases will provide confidence during refactoring or enhancement times. Writing test cases requires at least 40% of the overall development effort, so don’t underestimate this task.
Centralized error handling and other useful facilities that are needed across different parts of the application. This will help avoid committing the “duplicate codes” sin.
Make it a habit to do code review. This is a great chance for sharing knowledge and catching bugs before they become real bugs. In addition, this will help maintaining consistency, but not necessary eliminating it.
Small teams have better success in accomplishing something concrete in a reasonable amount of time. Nevertheless, make it a priority to communicate, via meetings, informal conversation in the hallways, or in someone’s cube.
This will also help catching wrong assumptions in a timely manner and have sufficient time to correct them. In addition, it will help building working relationship and making it more fun to work with your teammates.
Document the technical decisions that were made during the course of the development phase. Any time something requires more than one person to make a technical decision, it is important to document the details of the decision such as what was the agreement, the reasoning, and possibly other options were discussed. This is mainly because we have limited memory and the number of technical decisions is not small. The obvious benefits from doing this are you don’t have clutter your memory and you can easily defend your decision when someone asks about it 6 months after the decisions were made.
Being disciplined about following good programming practices through out the development phase is an important aspect. Among them are code review and writing unit test cases.
Often time during the initial development, some shortcuts or hard coding were made. Make sure to remove them as soon as possible. Otherwise they will create surprises and may cause missing the deadline. In our project, we delayed the need to integrate with corporate single sign on until it was absolutely necessary. When we finally took the plunge to do this, it requires more time than expected. We had high confidence that it will work so it was not a huge risk that we took.
Project schedule helps providing a road map to march forward to. The challenging part is once the schedule is public, it is almost an mandate to accomplish your work according to that schedule. The key is possibly to have private and public dates and preferably the later comes after the former.
A couple of days before the committed public date arrives, it is important to evaluate where you are. If you think you are running late, it is important to communicate this with your manager and possibly your customer.
Sometimes you need to see what’s are the committed features and possibly declaring the code completion without the minor features that your customers don’t care too much about or can be delayed to a later release. By doing this, you will be able to make your customer happy and at the same time you don’t loose the trust that other have on you.
Keeping pacing by breaking down your development cycle in a number of smaller cycles. This allows you to sprint and then take small breaks to re-energize. The problem with a long development cycle is that it creates an great opportunity to procrastinate and eventually you will be caught by surprise. Procrastination is a part of human nature and it is better to create an environment that promotes anti-procrastination.