Similarity ==> Higher Speed

It seems common for products or product lines to evolve into a collection of components, technologies, processes, etc. When components come from different companies or teams, it’s likely each has a unique dev culture. So what? As time marches on, a lot of change will occur, regardless of ones desire for the status quo.

Let’s take the position of adapting new components as they are. Depending on the size, the component may come with a build system that includes a differs source control system  than what is normally used. The path of least resistance is to adapt the new process as is. The team now has 2 processes & 2 source control systems…

Before you know it, team members move on; now the new folks are left re-building 2 mental models, processes, etc, assuming only one misfit component was added to the team.

Consider adding a small component of an odd language, say Visual Basic, into a C++ shop. Again, it seems efficient to absorb the original technology and it is. Until we get to our favorite, inconvenient team truth: turn-over. Developers end up supporting a larger number of technologies, but it’s likely their depth of knowledge is shallow. The “guru’s” who know everything may be blocked from moving on in the organization and the business is similarly hamstrung by irreplaceable resources.

A mature development shop will recognize the value of simplicity, which brings consistency across the board: work item delivery, build processes, testing environments, development time, estimates, security practices, code reviews, deployment, etc. Also, such a shop will understand the cost of “re-writing” as a part of the original cost.

The team will either re-factor the component to regain their speed or choose to lose performance.

Similarity ==> Higher Speed

Clear Requirements => Higher Speed

It seems that one of the early (and arguably immature) attractions of agile software development is that requirement gathering, discussion, decisioning & documenting was not necessary. All dev’s had to do was code, code, code! It probably didn’t help when every lame-brain idea was able to collect oodles of startup cash; it was imperative to code, code code!

As time went on and that next “great” thing became a legacy product, something inevitable occurred: team turn-over. With this, much of the institutional knowledge went out the door.

In these later years, the team has a mixture of old guard & late additions. The late additions find many perplexing practices, artifacts & technologies. The old guard has some recollection of the meaning, but not a precise or comprehensive understanding. A lot of time is spent re-discovering old decisions.

“But what about automated tests?”, you ask. Well, believe it or not, testers also leave teams. When the new testers arrive, they have no basis to form updated or new test plans, as requirements simply don’t exist. The consequence is that they too have many repeated questions, file incorrect bugs and basically have to start over.

Documentation has the same challenge; nothing to compare updates to. Again, they are in the “start-over” camp as everyone else.

Simply put (I think many understand this now), requirements are required for long-term success. A product cannot survive and thrive without the basics under control.

Clear Requirements => Higher Speed