by Art

Posted on Saturday June 06, 2015 at 02:40pm in Technology

When you're in the early stages of designing software, "You Aren't Gonna Need It" ought to be ringing in your ears. After all, you don't want to end up like this (courtesy of Jeff Atwood):

If your software development is truly agile, your architecture can evolve quickly in response to changing technical requirements. So start simple. But what do you start with? Some tech choices are so ubiquitous that you can be pretty sure you are going to need them. I give these a low "YAGNIsh" score.

In my experience, other technologies will tempt you, but should often be deferred until later in the project, due to a variety of reasons (mostly the carrying cost of the extra complexity). These are highly "YAGNIsh". Of course, this is only a guideline: your experience might tell you that you'll definitely need, say, a rules engine. But if you've never used one before, beware.

Workflow engine

This is a great example of something you can put in later, if you really need it. Almost all software has some form of workflow, even if it's just "reset password", so it's tempting to think that a workflow engine will do a better job than bespoke code. But you and your team are going to spend weeks understanding and then integrating that engine into the rest of your code. In my experience, the engine won't do exactly what you need either, so you're going to have poke around in the source (if you're lucky enough to use an open source one).

YAGNIsh score: 10/10

Source control

Here's an obvious counter-example. In fact, everything from Joel's 12 Steps has very low YAGNIsh. If you have experienced developers, source control won't be an overhead. Use source control right from the start!

YAGNIsh score: 0/10

(MongoDB|Cassandra|other NoSQL flavour of the month)

Are you sure a bog-standard, boring RDBMS won't suffice? Relational databases can process thousands of transactions per second. Postgres can store 32TB in a single table. Even the mighty Stack Overflow runs on SQL Server (with some caching, obviously)

"But, performance!". Yes, it might turn out to be a problem, so you should be measuring performance as early as practicable. It will help to gather back-of-the-envelope numbers on likely usage patterns. (You'd be amazed at how many projects do not do this.)

Of course, sticking with an SQL store has other advantages in terms of data integrity (such as a proper schema) and ease of reporting.

YAGNIsh score: 9/10

Message queue

If you have a distributed system, a message queue could well be a good idea. Maybe you have a third party component that's frequently unavailable or can only cope with a certain load, and you want to have automated retries.

Just remember that asynchronous programming is harder and less intuitive than the old-fashioned synchronous way. You have to deal with correlation and timeouts. Your stack traces are split in two or three. How long does it take a developer to reset the state of their message queue?

If you're not sure, start simple. Maybe instead of a queue, you could just use a thread pool to prevent blocking.

YAGNIsh score: 5/10

Database schema management

Free tools like Liquibase and Flyway manage your database using version-controlled scripts. Scripts can be in XML or plain DDL depending on your preference. You can use these tools on a fresh database, or apply them to an existing one that's already in production.

Like source code version control, these are essential, once you are in production. Before your first release, you might find it simpler to recreate the database each time with a single script (version-controlled along with the rest of the source code), since the data in the database doesn't matter. But it's a good idea to get your developers some experience with the tool by having a few practice releases.

YAGNish score (pre-release) 6/10

YAGNish score (production) 0/10

Third party identity management

If "social" is a key part of your application, integration with OpenID may actually save you development effort since you do not need to deal with saving usernames and passwords. You won't need to worry about passwords being stolen, or users resetting passwords they've forgotten (which is surprisingly complicated to get right).

On the enterprise side of things, you may not have much choice if your client wants single-sign-on across an existing corporate estate, so you might as well take the pain early on.

YAGNIsh score: 3/10

Let me know your favourite YAGNIsh technology in the comments!