Keep it simple

Life of a software engineer was rather simple, unusually simple with adoption of agile approaches; or so it seemed. Clouds seem to be coming back, and turbulence is back in the air

I have always looked at any change with simplicity as a yardstick, and that has helped all through. Any new change must be simple, because my business is delivering solution to my customer on time and budget; not learning technology, tools, standards or best practices, though they are of value as enablers. Indeed, enablers must be simple

Technology, tools, process, standards and best practices that you adopt must be simple to understand, adopt and use. If not, you have a problem in hand, for now and for ever. That is because software is developed by the team, not just an individual, and that team is bound to change over time. If what you are adopting is complex, you would need to get your team up to speed now and every time a new member comes in. Again, technology, tools, process, standards and best practices are bound to evolve. Tracking these, and ensuring that entire team is in sync, is a greater challenge. My experience is that these are not complex, in itself. Issue is made complex, by a myopic vision or dogmatic mindset.

My advice is: Keep it simple, always. Life is simple. Let us not make it complex

Let us get back to basics

Fundamental challenge of software development is to continually deliver quality software solution on time and budget. These are very specific goals that can be achieved and achievements can be measured easily and objectively.

Quality is not an ambiguous notion in the context of specific set of customers and end users. Schedule, budget and effective and efficient utilization of resources can also be easily and objectively assessed, monitored and controlled.

When projects fail, let us accept, it is a human failure, a failure of team work, a failure of individuals in the team. Time then is not to go into witch hunting, identifying who failed.

Business, requirements, technologies and team are increasingly dynamic. When these are not understood and communicated across the team, if priorities and progress are not measured, if motivation dries up, failure is a natural outcome.

We have what it takes to succeed, be it technology or process factors. List is endless: object oriented approach, best practices, estimation techniques, maturity models, unified process, patterns and anti-patterns, very powerful collaborative development tools. These, by themselves, are not going to solve the problem. On the contrary, may itself end as a problem, if used indiscriminately. We just need to put them together in the specific organization and project context, rather than hide behind a few technical jargon or introduce new ones.