Like any of the “firsts”, selecting a topic for the first blog entry is overwhelming me with choices. Having worked in the software industry for more than a decade now, I thought it would be fitting to start with a post reflecting on the eventful years I spent in building enterprise systems. Each role I have played and every responsibility I have assumed has taught me something that makes me who I am today and would qualify to be an interesting read, I hope.

Here is the top of my mind items on the factors that contributes to the success (or the lack of it) in building software.

1.  Define what success means, early on.

Customer pays for the software delivered. The success of a software project can only be measured in terms of the business or scientific impact it creates. Everything else is part of the process and generates artifacts that are produced and consumed till the end goal is met. In a typical cycle – developers receive specifications to build, testers receive the binaries to certify, and support team receives the deployable bits.

In a team setup, key to success hinges on the members’ ability to think beyond these immediate “receivables” while keeping the end outcome as the primary focus.

A committed and well bonded team with unified vision and focus can do magic. It can maximize the output by rallying behind the goals and objectives, and execute seamlessly. This also will result in problems being resolved quickly; work around applied for tactical issues of any kind and expectations being managed across the board.

Consuming or experimenting with a new technology will be too tempting to resist for the engineers in a team. After all, they derive deep satisfaction in building cutting edge and sophisticated systems. This is even truer when it is a v1 system that is being built. Managing the difference between objectives and fantasies will become hard if a definition of success is not clearly spelt early in the cycle and across all disciplines in the project team.

2. Communicate at all levels, there is no alternative.

Projects fail when communication breaks down. Maintaining constant touch points through the project cycle, especially when team members are heads down in getting things “done”, is a key challenge. It is in this phase of the project that the team will be faced with changes & magnified costs that make communication a key imperative.

Use face to face conversations to resolve issues and move ahead quickly. If an in-person meeting is not possible, talk it through over phone. Emails and other tools are good to document decisions taken during a conversation. When an email thread generates an instant flurry of replies and counter replies, it is time to pick up the phone or knock the other persons’ doors and resolve it right there.

Failing to document or articulate decisions made during a hall way conversation could keep stake holders and other individuals in the team at dark leading to assumptions and eventually unmet expectations. Always document and communicate decisions and leave no scope for unsubstantiated assumptions.

3. Stay course with objectives, more than the means.

Change management is a key aspect of all those software process models out there. If a change is not managed carefully it has the potential to wreck a project, even those which has had a fantastic start. A change in requirement or design is not a bad thing, if only managed and executed carefully.

“Hope” is not a language those binaries in the production servers understand. In majority of the situations, the Murphy’s couldn’t be more right; if something could go wrong it will. Identifying and acknowledging the hot spots in a solution as and when it arises during the execution and putting a mitigation in place is prudent than suppressing it or deferring it for the future.

Consider code-refactoring to be part of the process, not as change or rework. Though only production quality code can get into the source control, it is the usual tendency for the engineers to focus first on getting the solution up on its feet with features working. Once the features are complete, analyzing the loose ends and applying code refactoring will help in creating optimized and maintainable code that is production grade.

4. Take care of the bare essentials upfront, save time for later.

How many times have you ended up spending time in “compiling” those statistics for a project review? Especially during those crunch situations when you ought to be debugging an issue or running a test suite.

Process compliance and status reporting are a necessary part of the eco system. As much as a dev can understand the code segments in the source control, the management cannot be expected do the same to track progress and mitigate risks. Translating the progress and quality assurance checks in a format that the stake holders understand will reassure the entire project team.

Tons of tools and documentation are out there to help the project team publish these statistics in format acceptable to the stake holders. Adopt these process automation tools and train each member in the team with this right at the start. This helps save time later during critical phases of the project. It pays to take these distractions out of the way and let the team members focus in building the system.

Processes and decision making protocols established clearly and at the start will bring in the required discipline and streamline efforts across the board.

5. False starts & mirages have a heavy cost.

Unsubstantiated assumptions can wreck havoc. That coupled with false sense of progress can deny success by all means. Believing something is done when there is work left to be done is something the team should watch out for very carefully at every stage of the life cycle. Admitting slow progress and identifying ways to improve it is much safer than declaring completion based on some premature results.

In a project cycle, it is prudent to measure results only when things come to a logical point. For example, performance benchmarking mid way as the solution is being built may signal unreliable results and give a false sense of achievement which may not be sustainable.

Arriving at decisions at a premature juncture could result in magnified or underestimated effort resulting in underutilization or considerable stress later in the cycle. This applies especially to the coding phase that depends on appropriate details of the design to be in place before any meaningful work could commence with code.  

6. Play you strength, don’t be a drag.

Don’t be a drag in a team effort. Learn to exert positive influence in the team and encourage collective contribution. If there is one aspect that individuals can make a mark towards success of the team, it is by playing ones’ strength and by staying positive in the face of crunch situations.

When people with varied experiences and depth of knowledge come together, it is natural that the team conversations have to be level set at every instance. Learning to listen to others’ viewpoints however insignificant they can be, being self critical and coordinating with others towards common objectives are key to success. If you ever realize you have become a drag in a team conversation, step aside and let the team move forward productively.

7. Acknowledge and encourage diversity, in functioning and thought process.

Work place consists of individuals from varied background, having different beliefs and values. Though the commonness across all these binds the team together, it will be interesting to note that their priorities and thought process often doesn’t match.

Key to innovation and building impactful solutions relies on how much the eco system supports diversity and encourages the individuals to bring in original thinking in the context of the solution and execution. Diversity goes beyond the “out-of-box” thinking by individuals. It also includes the way individuals articulate their ideas, their style of functioning at work and their professional behavior and motivations.

When diversity is suppressed, individuals tend to be less motivated and creative ideas ceases to flow in. It would be in the interest of the project team to understand and encourage diverse thought process and utilize them in the common good for the project.

8. Learning is a continuous process, don’t time box it.

The pace at which the technology changes impacts our design and deliverables are very high compared to even 10 years back. The technology world changes while we are busy heads down coding for the immediate project priorities.

Learning and keeping oneself abreast of changes is not a point in time activity. Only an eco system for learning can help the individual in the team keep up with these changes. Unless this eco system is nurtured and developed, the next time you are in a design conversation or a problem solving situation, your work could become out of sync with industry trends and best practices. Such an eco system will include a steady stream of knowledge sharing sessions, discussion list & email exchanges and those informal hall way conversations.

Never procrastinate trying or experimenting something new on the sidelines that will help you with your next assignment or the project.

9. Bring down the walls, encourage collective ownership.

Resolving tactical issues during execution becomes painfully long drawn and often chaotic when conversations become “us vs. them”. During those heated moments, it is pays to take a step back, look at the big picture of what is at stake, and strive for a middle ground in achieving the deliverable. Dismantling those inner walls within teams and encouraging collective ownership does help in resolving issues faster and brings in a greater sense of achievement at all levels of the project.

10. We are building software, have fun in the process.

 “When the game is over, the king and pawn goes into the same box”.  This metaphor applies even to project teams. After a project draws close, only a well bonded team can keep up the motivation, retain the lessons learnt and take up the next challenge with greater confidence.

Appreciation of work at the right time and mutual understanding of issues towards common goals will go far beyond the immediate delivery. The feel good factor that exists at the end of it on the work delivered will help the team in achieving greater results and set it up for successes in the future.

Well, that is an inclusive list in no particular order. I am sure each of the point noted above deserves much more coverage. If you are with me till here, thank you for listening! J