Lip Service
The internet is a fast paced world where the general consensus about what is "cool" can change in instant, and the online software development community is no exception. Recent years have seen movements relating to topics such as craftsmanship, quality, and design spread like wildfire through the tubes, eventually crossing over into the real world in the forms such as books, conference talks and user group meetings.
If consulting companies are good at anything, it's recognising trends and jumping onto band wagons. Many organisations have seen the movements within the development community as opportunities to gain new business, attract employees or quite simply make some cash. Others are staffed by people who are not quite "in the loop" enough to be part of the original movement but still want to be seen as participating even if they don't understand the finer details of what those wacky internet people are talking about. This has seen a large number of IT consulting firms attempting to align themselves with a wide range of topics/buzzwords such as Agile, TDD and SOA.
This alignment process has lead to a rather disturbing trend of companies making bold statements about the "minimum standards" that their teams must adhere to. I use the word "disturbing" for two reasons:
- The minimum standards are usually ill-conceived or miss the core principles of what the original movement was trying to say
- When push comes to shove, they are not actually enforceable, leading to uneven application or even complete abandonment of the "standards" dependent on client or project
Consulting firms have been missing the point in an attempt to "me too" the latest trend, so no surprises with the first point; just ask for a definition of Cloud Computing next time you're at an industry conference to see that in action.Still, in some cases there is still some value to be gained out of the application of the misinterpreted principle. After all, the Code Reviews touted by a firm may be nothing more than a soulless checklist designed to cover behinds rather than improve code quality, but at least it's a start.
Now, setting aside that what these companies are trying to implement isn't all that great in the first place, it's still amusing that there seems to be a huge lack of understanding around the meaning of the word "minimum". If you're having trouble, let me Google that for you. If you have a set of standards, then say that a certain set of those standards is the minimum that you will apply then those are the smallest set of standards that must be met. In fact, it should mean that a project crisis meeting is held or intervention is required if you don't actually meet those standards. If a standard is not enforceable, or you don't apply them in specific circumstances then it is not a part of your minimum standards; you may wish to refer to it as a "nice to have".
I have a sneaking suspicion that both of these points are inherently linked; companies are keen to ditch their principles at the first sign of trouble simply because they do not see value in them, and the reason they do not see value is because they fundamentally misunderstand the reason for doing it in the first place. Take TDD, for instance. If you tell someone that they have to write tests for the sake of writing tests, and don't have a discussion or opinion about test-first or TDD as a design activity then they're probably not going to get any real value out of the activity. It will be seen as extra work with no pay off, and eventually people will start to avoid writing tests like the plague. The lip service approach just isn't enough to convince people to change their principles and values, at least not in the long term.
If you work for a company like this, it's important to realise that all is not lost. Someone above you in the organisational chart thought that the standards and principles were important enough to write up a PowerPoint presentation on, and maybe even paid for some basic training. They see a value in it (be it a cultural alignment with their own beliefs, a financial benefit or something else), but for whatever reason they just don't properly understand what the end product should look like. If you see a topic that is near and dear to your heart being butchered by your employer, find the person who is doing the butchering and help them understand. Explain what the concept is really about, and what the real benefits are. Even if they just want to ride the buzz word wave all the way to the bank, they still want to see it succeed, leaving you with an opportunity to nudge the ship in the right direction.
