Bright Shiny Objects

Bright Shiny Objects abound.

If you attempt software development for any length of time you will encounter Bright Shiny Objects. They come in multiple forms. They could be the latest features your competitor has in their products. They could be the latest language, which uses the latest language feature, which will save us from the latest looming Y2K disaster. Or it is a new platform which will make everything self managing. The list is endless.

If they have one thing in common it is newness. All things new tend to have bright shiny exteriors. Part of the draw is simple curiosity. But for developers of any moderate experience there is a deeper pull.

As I pointed out in “The golden first year" you get paid for your experience. Thus you get paid in your next job for what you did in your current job. If you lived thru the tech bubble you saw this first hand as html developers were paid more than client server whizzes.

Technical people are excellent problem solvers, so it does not take them long to realize this dynamic and solve it by loading their current project up with all the current hot Bright Shiny Objects.( Your website may have no real use for AJAX but you have it now.)

The danger is Bright Shiny Objects tend to be loaded with Poisoned Candy. Poisoned Candy are those features or tricks that make the Bright Shiny Objects work in limited circumstances like development or in a beta situation but fail horrendously in production.

Unless you are eternally vigilant, you will find your project overrun by Bright Shiny Objects and their problems. If a developer wants to use a Bright Shiny Object, you are going to find it nearly impossible to stop them. Keep in mind, that even if you control their employment, they perceive that the market will reward them with a better job in the short term if they can master this technology.

So what can you do?

Insist on Small Doses and Results. Ask the developer to do the smallest thing possible with the Bright Shiny Object, and give it a short deadline; a day or something less than a week. If it is more than a week it runs the risk of evolving into a project of its own. As soon as something is displayed insist on running it through the entire process all the way up to the edge of deploying it to production. This will reveal all the poison in the candy.

Occasionally there is no poison and you have found a better way. Congrats and beware. The more likely case is a mixture of good and bad. Here you will have to insist that the defects be remedied by making the developer address them. By sharing this pain with the developer they will start to gain an understanding for the dark side of Bright Shiny Objects.