Minimal IT logo and link to home page
Research, training, consultancy and software to reduce IT costs
Home | About | Newsletter | Contact
Previous | Next Printer friendly
15 February 2011

You Aren't Gonna Need It, revisited

By Andrew Clifford

It is better to spend time on system structure, documentation and testing than on adding features that you do not currently need.

You Aren't Gonna Need It, or YAGNI, is a programming principle which states, "Always implement things when you actually need them, never when you just foresee that you need them."

YAGNI saves time because you do not develop features that you do not actually need. YAGNI keeps your code simpler because it is not polluted with unnecessary features. YAGNI is realistic because what you imagine you want now will probably not be exactly what you do need, when you do finally need it.

I try to follow YAGNI when developing systems. However, recent work on our Metrici Advisor product has made me question whether we have been applying YAGNI too much.

We have been adding a new feature to allow user-defined server-side code in JavaScript, for example to provide custom calculations. Previously, we had not considered providing a JavaScript interface. However, we do have an XML-based service layer between the front-end user interface and the back-end functionality. We also use this to provide a web services interface to the product, so it seemed a suitable integration point for JavaScript.

Using these services in JavaScript has been frustrating. Although the services are just what we need from the user interface, some are difficult to use from JavaScript. For example, to identify data, we use either internal numeric identifiers or text references. Some services use one, some the other, some either. Some update services return data to redisplay a page, others do not. And so on.

This has made me wonder whether we had applied YAGNI too hard. Had we created services which were so specialised to the user interface that they are not good candidates for reuse?

While reworking some of the services and making them more usable from JavaScript, a number of things made me realise that our original decisions were reasonable.

First, we have good tests for these services. Adding a new option is not that hard when your tests guarantee that you are not going to break existing functionality.

Second, we have reliable documentation. This makes it easy to understand what is going on and, for example, work out how to add options that do not invalidate existing calls.

Third, the system is reasonably well structured. For example, we use a parameter parser to interpret service parameters. More recent services use an improved parser which can use either internal numeric identifiers or textual references. We can simply slot this into older services to make them more usable from JavaScript.

Although it is frustrating to rework old code, I think on balance we were right to keep the services simple initially. If we had added to them, we would probably not have added exactly the features we need now. And by spending our time on design, on documentation, and on testing, we did prepare the services for future use.

So is YAGNI worthwhile? When it comes to functionality, You Aren't Gonna Need It is a good principle. But you are going to need testing, and documentation, and good structure, so spend your time on these rather than on building functionality that you might never need.

Next: Nightmare of the typing pool


To subscribe to the newlsetter, simply send an email to
Privacy policy

Subscribe to RSS feed

Latest newsletter:
Magical metadata

We use the term "metadata-driven" to describe IT solutions in which functionality is defined in data. Taking this to the extreme can provide unparalleled levels of speed, simplicity and versatility.
Read full newsletter

System governance

System governance helps you implement high-quality systems, manage existing systems proactively, and improve failing systems.

Try it for free!

Find out more