Core first, improvements next, details last with specifications buzzing around
05/11/2026
Most IT projects fail.
Some fail while costing a lot (or making a lot of money, depending on the point of view).
The few that succeed likely follow these simple steps, in that order:
- Core first
- Improvements next
- Details last
…and the writing of specifications buzzing around.
Core first
This is the most important and difficult part of an IT project: to identify what is the minimal list of features that would deliver a useful service. It must be useful but it must be scarce.
A good indicator for this step: if you can do without, it’s not in the core.
Heading directly to a whole bunch of nice-looking goals is sure to lead to a total waste of time and, eventually, failure.
Improvements next
That’s the easiest part. Once an IT project is launched, two things come flooding: bugs and requests for new features. Even if all precautions were taken, thousands of tests were passed, there will still remain some bugs, lurking in marginal cases. Bugs love marginal cases, those that escaped the careful, merciless hunts. Another source of bug discovery is the users’ imagination. Especially since, for one developer, there are hopefully hundreds of users.
But users’ imagination also brings batches of new feature requirements. There is no better context to get some new idea of what could be done to improve software than to use it. Besides, contrary to features thought of in advance that sometimes prove to be useless, after a lot of time was lost on them, users’ requirements are sure to be useful. At least users will endorse them ;-)
Details last
Details must come only when the core features, completed by the users’ requirements, are fully provided. That is not to say that details are superfluous, on the contrary, they alone make the difference between a boring and an awesome application. Usually, developers love to linger over their otherwise completed job to add details. The customer who pays for them likes them less, nothing is perfect.
Specifications buzzing around
Specifications must be written in plain English, with as few technical details as possible to be intelligible to anyone, without any room for discussion. They describe what the software does, accurately. Their role is crucial for the two most important conditions of the software’s future: maintenance. Yes, maintenance is twofold: deciding which are bugs and which are new features to be able to fix the former and add the latter.
Why buzzing around? Because specifications are written neither at the beginning nor at the end of the project. They are written all the time, before, during and after each step. Pretending to be able to write them prior to any coding is at least pretentious. Writing them after an important amount of work is done usually ends in forgetting some part of it. Besides, specifications evolve during the coding process, when what was foreseen reveals itself to be a not-too-smart idea after all and new solutions appear on the way.
Following the simple common sense organization: core first, improvements next, details last with specifications buzzing around has allowed numerunique to build software that met users’ expectations and lasted.
Written by human, text reviewed and image created by AI under close human control.