Some people have not only some good ideas but can also bring these into practice successfully. Hence, they are always surrounded by a small group of enthusiastic followers (hey, where have I heard this before? ).

In software engineering this is not any different. Usually an experienced professional continuously gathers all his best practices and lessons learned and takes a slightly different approach for a new project every time in an attempt to avoid glitches encountered in the previous ones. Most of the time, these changes will focus on a certain aspect in software engineering.

For example, if in such an environment  user-contacts appears to be difficult, the change will be around techniques to get users more involved like in agile methods. If the circumstances have made data migration more than a usual challenge, the new approach will be more strongly based on information modeling. If the technology is new and different, the software architecture might be enriched with some new elements. If a project is based mainly on of-the-shelf components, a more package-based approach will be necessary. Or new “priorities” in business or technology like Business Intelligence, Mobile Apps, and Offshore or Service Orientation ask for distinction, and so forth.

As a project team usually consists of more than just one software engineer, gradually a group of people emerge all with the same knowledge and experience. So far so good, especially when they deliver successful projects. But when it gets bigger, other things have to change too. The new aspects will definitely have their impact on deliverables like the plan, planning, dashboards, or other design intermediates and probably also on environmental conditions like tools or support. So slowly effects of this new change pops up in a lot if not all artifacts in a project. If then someone takes the “bold” step to develop training material for newcomers or writes an article about it, and a new “method” suddenly emerges .

The point is that probably 80 percent of the work executed in these projects is not that very different from those in the past. After all, the changes were driven by certain lessons learned around certain aspects. But looking from a distance, now we have a completely new approach for projects in all its aspects from project execution to project management. If the group of people to roll out this method gets big, the amount of time and money to spend on proper deployment will become an unbridgeable gap. Furthermore, differences in technology will probably create additional and separate “branches.” For instance, an approach for packages and one bespoke. Or, a special agile variant versus one for predictive.Newcomers will often only have the chance to get the “overview training” covering a lot of obvious and known aspects of software engineering and this will not be enough to make them more productive but is only a starting point for self-learning. Or, they get only the training in the branch “locking” them up in that knowledge area and making them less exchangeable with other technology environments.

All of this would probably lead to new glitches, lessons learned, best practices, new methods and tools, which by itself is not that bad but in a business and profession that is under economic pressure it is undesirable. Severely undesirable. Either the educational costs are incalculable or overruns increase again due to too little training or utilization will drop again because people are not exchangeable anymore.

Have fun becoming distinctive 

Be first to comment this article

Write Comment
Name:
Comment:
Code:*