Acceleration of the Ever-changing Development Environment

It is hard to believe it has been over 10-years since defending my master's thesis.

Back in 96/97, the world had about 4-years of exposure to the commercial web ... it was already so clear that the impact on software engineering was going to be most acute to the development environment.

Consider this ... there was no major company nor major revenue-generating project built with Java back in 96. C# wasn't even in use in academia, much less any production system in the private/public sectors.

Jump forward to today. It would be boring and rhetorical to list the overwhelming number of new programming languages introduced since Java and C# were born.

Of course, core programming languages are only a slice within today's array of tech stacks. Even in tightly controlled dev team environments (and much to my dismay), I've come to expect to find developers using differing vendors/versions of compilers, IDEs, browsers, operating systems, app servers, collaboration tools, etc., etc. Imagine the number of permutations of development environments this presents ... and within even a single team that is said to be striving to accomplish a single primary goal: to produce a stable, predictable, and maintainable product.

And ... let's get to the point of this entry ... there is a clear acceleration of the ever-changing development environment.

There is no doubt in my mind, based on my consulting experience working with distinctly different teams on distinctly different projects each working with distinctly different development environments, things are getting even more complex. The amount of permutations is accelerating ... rapidly.

The impacts of this are scary. The productivity of a development team working with such distinctly different development environments can only suffer. Sharing experiences/tricks/tips/solutions with these colleagues, bringing new team members into the fray, picking back up on a project written a few months back w/o the original engineers ... these are serious and real problems. They are risks to every project I've been involved in for over a decade ... and they are rarely managed.

So, how do we manage this risk of the acceleration of the ever-changing development environment? Of course, there's no 'silver bullet' here, either. However, I believe it is manageable. Team leads *must* enforce a consistent development environment across their team. Yes, there will be those that are resistant to this ... there may even be those that choose to move on to other projects. IMO, good riddance.

This is a topic that I believe I'll discuss more going forward on the blog (since I've been such an avid blogger, eh?). In the meantime, team leads ... try this:

Before your next project gets too far into the PoC/prototyping stage, identify what development environment seems to be the most appropriate for the project kick-off. As members of the team begin to come on-board, ensure that they are competent with the target environment ... or at least capable of being productive in that environment in short time. Then, enforce it for the first iteration of the project. On each subsequent iteration, reevaluate the development environment ... ensuring it is still the best stack for the upcoming iteration. The environment *will* change, but it must be managed and must be consistently used by the development team.

Remember ... 85% of all software projects fail ... it stands to reason that chances can only improve by following this simple tactic. Till the next post ... happy coding!