I remember the influence of “Getting Real” — the book from the folks at 37 Signals — in my early web development projects back in the day.

The message was simple and clear: start at the core process of the application, preferrably at the UI level, and then expand both sideways to other connecting processes and then layer wise through the application’s tiers. But, in short, the idea was to start right there in the middle of your product’s journey.

The perfect allegory would be to imagine your summer vacations by just thinking of yourself enjoying the sunset sitting on a chair at the beach. Which beach? Well, it can be any beach, anywhere with a coast to the sea, anytime as long as you are there for the sunset and the Margarita.

The problem comes when you realize there are plenty of stuff that has to be arranged between your current state and the core process implemented in the app. The arrangement is never linear. It may be logical, especially in data intensive systems where processes can only be built around data completion — the next table needs an FK from the table your are working on.

With time and practice I found out that it’s possible to enforce a logical path in development by having an “admin” module being developed in parallel with the core app. A process that resembles TDD a little bit. Not that you would develop the admin interface first and then the whatever process or feature, but just to think that the current process must be supported or “reflected” in any way.

An extreme example — and borrowing the scenario from Getting Real — is to design the UI of the core functionality and then design the admin view that will control access to that feature. Or, even before that, control the access to the service as a whole. Or… maybe before that, control the access to the entire app by implementing an universal sign-in/up “kill switch” you can easily manage from your admin module.

Oh, but the switch is off, how could you even access admin to manage things in the system. You need to give it a thought and maybe create a module detached from the app monolith. Time for yet another allegory: the module is the hotel administration office that runs outside the hotel’s premises. It operates across the street in a rented room of a random building. If the hotel burns in fire and then collapses, there will be folks nearby with operational capacity and resources to do something about it.

Putting all the drama aside, having the admin module at least in mind early on in the project is a good way to keep the management topic alive in the team.

Having an admin module live and operational since day one — even a static html with links, the good old “index”, yes! — it’s a good practice, in my view, to establish the project’s grassroots to the team and make the product flourish.