Every entity in this world will go through this cycle of living and dying. Nothing shall escape it.

This applies to the most obvious entity of all, our own self. However this also applies to other concept in life. Take for example, a computer system.

A computer system is often the result of a software project. There is the moment where an idea is being formulated, a prototype is built to pitch the project, budget acquired, team formulated and grown, and finally, the project took off (birth). Over time, the system is crafted, again and again it is perfected, broken, fixed, patched, deployed. installed, broken again, fixed again, and so on (aging).

However, as software system changes hand from one team to another, fixes and enhancement done to it may or may not be in accordance with the original structure conceived by its creators. This will eventually result in various internal complication and inconsistencies. Sometimes it is not the software that age, but the hardware. Disks failing, cables aging, memory corruption, dead power supply, and so on. Indeed, nothing last forever! (sickness).

Finally, at some point, all software system will be retired. It may became obsolete, replaced by a newer system, or simply, broke down (death). On that fateful day, management, end-users, or whoever it is that work closely with the system will eventually look back and reflect upon the value it has contributed to the organization or end users. Even future systems implemented will be measured, directly or indirectly, against its older counterparts.

Therefore for those of you who works in the realm of computing, do keep in mind this principle. Take it to your heart that nothing in this world is permanent.

In doing so, when crafting and scoping a system, it is important that we ask ourself (and the client) – what is the intended lifecycle of this project or software system? how will it be supported and maintained? who will look after the system when your team is gone?

Remember that a software system is an entity as much as you are. How you write each of your system reflects your view and life-state in general. And verily so, you can infer the character of a programmer from a piece of code that he has written. From the various decision points he made which is visible in the way the system is structured, organized, partitioned and optimized.

Have that system lived a life worth living?

Well, have you?

Indeed it is true that truth emerges and lies stripped bare when one reflects upon Death. When the system has reached the end of its live, and your name written as craftsman of that system in the various source code and documentations that surrounds the system, how would you like to be perceived?

So if there is one credo for a programmer to follow, this would be it:

Live a life worth living – Craft a system worth crafting.
The two goes hand in hand.

Well, as I was restructuring my room, I realized that what I am doing is very similar to refactoring of source code (in the context of computer programming). Basically, you take a step back and assess the following things:

• What are the tasks (use cases) that got executed most often
• How does the facility (in this case my room) get used to satisfy those use cases.
• If I were to start with a clean slate (a blank room) how best to rearrange the components, as well as the parts within each component to best satisfy the requirement?

Usually when people rearrange their furniture around, they are mostly concerned with only space, looks, and feel of the room. But what I did today was more than that, of course I think about space – I think about the limited area in my room that are not used very often and re-arrange my bed, study desk, and shelf around based on that.

But more than thinking about the placement of things, I also think about stuff like:

• Where should I store my recent documents, vs my old documents?
  Where should my old documents live?
  I settled with putting recent document on the right end of my desk, and archived documents on the bottom shelf. I rarely access these old docs so firstly, it make sense to put them on separate pile. But the question then becomes..
• How should I archive my old docs?
  I settled with sorting and storing them in chronological order, by projects / case. I put them on a small box each. I don’t open up old docs regularly, (else they will not be called old) but when I do want to find something older than 6 months, it usually take ages. To partition and archive it this way feels right for me. Loving the outcome so far.
• Where should I put my boiler?
  Because I’m a serious fan of tea, I actually moved the boiler up from the kitchen into my DESK. I reckon there’s no need to go downstairs to get hot water if I can just boil them right in front of me. Again, loving this decision so far.
• Where should I put my guitars?
  I actually noticed an area in my room that I don’t use a lot – it’s actually a walkway to the balcony. But because it’s usually very windy and cold outside, I never accessed the balcony. So I turn this area into my mini reading area and I put my guitars close to it. Instant mini zen space. I just sat down there after dinner strumming stuff out. That mini space rocks.
• …And so on and so forth, you get the idea.

I know, right? This is so geeky, LOL – But it surprises me that the thought process I went through is VERY similar to refactoring the source base for a computer program. Even the dilemma at the middle of the procedure is also very similar – while I was restructuring there was so much mess in my room (I can’t walk in a straight line!) that I doubted whether I was actually adding some real value or whether I was just in the mood of shifting things around. If you are a computer programmer that have experience in undertaking a big refactoring ‘surgery’ – you should be familiar with what I am talking about.

Anyway, all in all it turns out that the restructuring was for the better. I’ve moved old books I don’t use downstairs to the big shelf where all books live, I’ve reclaimed areas in my room that I don’t use very often into my mini zen space, and my book shelves – even though it looked the same, now the areas within it are partitioned and each partition have a purpose that better fit my current need.

In short, my room now satisfy the requirement better.

I know, I can ready your mind – WHY THE HASSLE? IT’ S JUST A BLOODY ROOM!

Yes, all of the stuff I’ve mentioned here are all small things – boiler placement, document archival policy, reclaiming spaces – they’re all just ‘insignificant’ details. I mean it’s just a room right? It’s so easy to just put stuff in and be done with it…

But so is refactoring a computer program. Indentation, comments, function signature, separation of concern, re-assessing the role of a class, a module, a package, and so on. So is about being organised, being punctual, being disciplined, being mindful, and so on.

All of this are just small ‘insignificant’ stuff. But add all of those small things up, and you will find that the cumulative sum of those things defines your limitation. The short term reward of fixing each ‘insignificant’ problem is usually not very noticeable – but in the long run, the reward of removing or reducing a factor that limits your ability to function more effectively, more in tune with your personal self is well worth the trouble.

How’s that for room restructuring philosophy?

So tonight, before you go to bed, if you feels like taking a spin at this stuff, go and stand in a corner of your target room and really think about what you want to use this room for. What is its purpose? And in doing so, still with your ‘organizer’ goggles on, look again at all the components inside it. Does that stuff fit in the room? Does it feels right to have those stuffs there, positioned that way, arranged and partitioned that way? If not, and you genuinely feel that – then the question is not “why take the trouble to move it around?” – but rather “why NOT move it around?”

After all, isn’t this the essential way of personalising your, well, personal living space?