Some Creativity

I am fortunate enough to work with a couple of great individuals. Recently I was able to hypnotize persuade them into discussing things which should and shouldn’t be done in a software project

I am absolutely sure that the discussion will help me in the future (and them). However I thought the merged list is generic enough to help anyone, and hence this post.

In the beginning…

• Before you start on a project, follow up with your managers and ensure that a detailed feasibility analysis has been done. This should include business planning, market analysis, and of course technology investigation to identify major road-blocks that are likely to be encountered in the future. For the technical analysis, you must involve the person who is going to actually write most of the code later on – because he’s the only one who’s most likely to consider all the possible issues.
• Involve engineers during requirement gathering phase. If possible, ask each of them to take a good look at a system of other competitors and report back with their findings. This will help the Product Manager in that there’s a better guarantee of the surface area of features being covered. The other bigger benefit is that the engineers would have a much clearer idea of the sort of product they’re supposed to build without having to read hundreds of pages in the requirements documents. This will also make them, I believe, more receptive to changes made in the requirements later on as they’ll have a better picture of the landscape. Being receptive to changes is very important.
• Identify major fears and unknowns that can negatively affect the outcome of a project. Make a proactive effort to address them at the start of the project.
• Make responsibilities of all individuals involved in the project clear for accountability. Assign roles to them appropriately.
• There should be a designated Project Manager whose role should be to maintain timelines, and escalate issues up to and from senior management. Asking a person in another role to also perform as a PM might not be effective always.

Day to day…

• Obtain sign-off for technical decisions and have a general plan for proceeding if a sign-off is not made within a specific amount of time.
• Daily standup meetings help a lot in keeping every one up to date on status and outstanding issues. There’s a lot to be learned from body language which might otherwise be lost in other forms of communication. However it is important to keep the meetings short – 10 to 15 minutes. There’s lots of literature about how the meetings should and shouldn’t be done. I’ll just say that you need to try out different things and pick the one which works best with the personalities of the individuals in the team.

In the meetings…

• Long weekly meetings drain the energy out of people and consequently the project. While I have my doubts on whether people pay attention after 45 minutes on average, I have even stronger doubts on the effectiveness of the meetings that go on for more than 2 hours. There might be exceptions of course, and I’d be interested in knowing what they did differently.
• After the weekly meeting, ensure that the meeting minutes are sent out describing each item discussed in the agenda along with the decisions made, open issues, and action items (assigning a person responsible).
• Be on time in meetings. Try to attend the meetings physically instead of over phone.
• Try to avoid taking calls on your cell phones during meetings – especially when you are actively involved in a discussion.
• Making decisions based on consensus is not always effective. Making decisions without considering inputs from others is equally bad.

When conducting code / design / UI reviews…

• If the process is to do design / code reviews in the meetings, to make the review more effective, try to restrict the number of attendees to the minimum absolutely necessary. Assigning reviewers to subsystems, if possible, might help in this regard.
• When performing a code review ensure that you enforce the positive aspects of the code, while identifying the aspects that need improvement. Too many details are bad; only give as many specifics as you think are needed to send the developer whose code is being reviewed forward in the right direction. When performing a review, pay attention and make an honest effort to understand the problem being posed to you.

When your code / design / UI is being reviewed by someone…

• When asking someone for a code / design review, make a dedicated effort to get their feedback. This might require you to spend an hour preparing a sample application to demonstrate the problem, but the time spent in it would be worth the effort. Be open to feedback. Negative feedback is still better than no feedback at all.

In general…

• Do not shoot down ideas point blank. This erodes the enthusiasm of the contributors which is very difficult to get back. Make sure you identify the positive aspects of every idea.
• Do not be afraid to hire temporary contractors and subject matter experts if required. That’s why a feasibility analysis is important.
• When involving new people in a project, ensure that they have received adequate training on other internal products and frameworks as required.
• If you’re required to use a common piece of code, ensure that it has an adequate test-bed. Secondly, push for dedicating engineering resources for their maintenance, depending of course on the size of the common code. If there aren’t any developers accountable for the upkeep of the common piece of code, you’re likely to lose the confidence of the developers who’re supposed to use it.

But most importantly…

• Work to a level where you can be proud of your contributions tomorrow. In the end, that’s all that matters.