As I’ve noted in the past, it really helps to understand the techies‘ way of thinking, especially when trying to get work done on tasks that are decidedly non-technical. Here’s two more recent stories from work, both hinging on the common desire to just “git’er done“.
Why do we waste time removing obsolete code? Just hide the menu option …
A few months ago, we had a task to decommission a chunk of code that was calculating some elapsed time information (ET). It was a great concept when originally added to the system, but the business found that it had little impact in reality. Why not just take the information out of the reports? A quick and simple fix …
Flash forward: we were recently having performance issues with some batch processes, after putting in a new bit of code [note: in an area totally unrelated to the ET stuff]. We had crossed a timing threshold; the batch was hitting it’s upper limit on a time window. This was a fairly critical business requirement, so (unfortunately) other projects felt the impact as the team dropped everything to put all hands on this issue.
Turns out the fix was to take out the old ET code that we weren’t using – voila, the performance issue disappeared.
A classic example of why it’s always worth the effort to decommission code that’s not in use anymore. Just commenting it out, or leaving it in and ignoring the work it does – well, it may be the quick way to get the issue closed, but you never know when that crufty old code will come back and haunt you.
The other reason, of course, is to simplify the testing of version upgrades and bug patches for the underlying enterprise software. The more cruft I leave in the system – that adds no value – just increases the drudgery of testing time – testing stuff that we don’t use anyway.
I like to point out that I’m a calm and lazy guy, and I hate to work on fire drills and pointless stuff. A little extra work now can eliminate untold amounts of work in the future.
Why do we waste time on all this “administrivia” – formal status reports, project documentation? Even for the simplest tasks!
This was a tougher conversation, as the “vision adjustment” pertain to folks with management ambitions. The classic challenge for IT departments is to demonstrate alignment with the business, and justify budgets – improved tools, incremental headcount, etc. The solution, of course, is to go to your excellent knowledge base of projects and results; here’s the problem, here’s what we did, and here’s the results.
But wait – we didn’t document what we did? Ooo, now I have to justify all these requests based on my excellent memory (which, I can tell you, is often comically poor – hence all the writing …)
We must realize that The Business Side (them) are not dense; they’ve just got a lot on their mind. If IT has a good relationship with The Business, and the organization is small enough, we might be able to remind them of our successes over the past year – and if business is good and budgets are loose, it might work. But when dollars are tight, and we’re competing with other areas of the business, it helps tremendously to be able to point to a clearly documented track record – problem, solution, results.
Why do we waste time … ?
The key is to appeal to the systems thinking mentality; pulling a lever on this thingamajig over here affects that framistat over there. This is time invested in the short term that will pay off in the long term.
- Why do you put asserts in your code? Why do you architect failover servers? Preventing unfortunate things from happening in the future
- Why do you code for reuse? Why create disk image standards? Some extra effort (one time) now, less effort (many times) in the future
Authors Note to Self …
My significant contribution to the universal knowledge base for the day – added the word framistat to Wikipedia. Better update my resume …
This Post Has 0 Comments