The YAGNI Effect

In the scramble to innovate, companies often add unnecessary complexity to their development processes. Unfortunately, this means the application development industry is just as susceptible to fads as any other industry. How do you know the tools you are using actually adding value to your process?

The idea for this week’s post comes originally from one of Andrew Binstock’s posts on Dr. Dobbs. I wanted to expand on his point and clarify the application of some of his ideas. In his post, Binstock addresses a syndrome a lot of enterprises contract when getting into the rapid application development world—“featuritis.” This is referring to the perception that adding features adds value, even if those features are never used.

Featuritis leads to waste like in the old story from the space race; why waste money on feature-packed, waterproof, zero-g pen when you only need a pencil? To avoid that scenario, it sure would be nice when contemplating new features to have someone looking over your shoulder letting you know, “you ain’t gonna need it.”

Features you need, features you don’t

Of course, I’m not advocating a completely barebones approach to application development. There are a lot of tools out there that truly do improve the process through the addition of useful tools. “Useful” is the key word here. If a feature is not being used, it is not worth your time. But when adopting new tools, how do you know what will be useful and what will not before you adopt them?

The simple answer is this: do you research. Seek out as much information as possible about a product before you buy it so you know exactly what you are getting into when you do. Compare products with each other. Seek out customer testimonials to get a good idea of how others in your industry are using the features of the product… and to be sure those features are being used at all.

Another big part of research is actually getting your hands on the product and trying it out. That’s why many products, including Progress® Pacific™, have fully-featured trial periods that let you figure out how they can help you before doing a massive roll-out.

4 Simple rules

While you are doing your research, you should keep these guidelines in mind:

1. Only adopt a product if it has features you need and will use in your development process.
2. Avoid products that offer “advanced” interfaces if that interface gets in the way of development.
3. Engage your development team in the decision process. They will be the ones using this product every day, and it is important you know what they need.
4. Make sure you let your coders write code! Be careful your new product doesn’t take too much control over development out of their hands in favor of a “simpler” process.

You ARE going to need it

With all of that in mind, what features should you looking to add? Right now, the answer seems to be “process management” and “integration.”

Remember that for most programmers, coding is a creative act. Too often do developers get bogged down in administrative junk. When they are struggling to check boxes and meet design requirements, they don’t have much time or energy to devote to thinking of new features or finding ways to improve efficiency. A platform that is able to handle all of that stuff in the background will free up the development team to do what they are being paid to do—develop high quality applications.

At the same time, integration tools add value by allowing a project to live in a single place throughout its lifecycle. This means that developers don’t need to go hunting through their hard drives for scraps of code or loading multiple programs to manage things like QA requirements or databases that are required for the app to function. Having everyone on the team looking at the same interface, working together in real-time means fewer communication-lapses and means the job can get done right the first time.

Both of these features are commonly found in Platform-as-a-Service (PaaS) offerings such as Pacific. What’s better is that they are easy to implement, and therefore, more likely to be used and not become extraneous features “you ain’t gonna need”. All it takes is establishing a common workflow on the PaaS, and it takes care of the rest. It’s the perfect cure for “featuritis.”