As much as humans love to multitask, we are still better at doing one thing at a time, well more precisely, we still do one thing at a time, even when we multitask, assigning a quantum/time-slice to each task. Much like the use of a time-slice process scheduling algorithm, multitasking is not free, the cost of context-switching still exists, to most of us, that means getting in the ‘zone’ for particular tasks. Unless of course you have some form ADD or ADHD, then you thrive on the ability to multitask and having many things to do at any one time. I find however that even this basic idea is often not recognised in the workplace, developers need contiguous blocks of time to effectively get work done, constant swapping of priorities, or frequent meetings are major hurdles to producing effective and quality code, and thus quality software.

But of course, for many places quality software is not a priority, software that works in as far as the customer is concerned is what matters. Even if the poor codeform (I’d say lifeform, but then you’d think I’m crazy which would be true too…) is hurting inside, begging, nay crying for a refactor, as long as it does what the customer asks, all is well. Sometimes this is fine, especially when we code to unreasonable requirements which really mess the code up. Reminds me of a tenet from Kernighan & Pike’s The Practice of Programming on programming for the general case first. Non-standard requirements often break elegance and symmetry. This is not to say they’re wrong of course, but they take a bit more effort to get right in software engineering terms.

A digression (I love doing this): one could argue however that given more time, one could modify the code so it remains elegant in handling the strange requirements. One could even argue that if there are a lot of strange requirements, either the customer or the developer or both have not really translated the domain’s needs into a software-consumable form (read: modeling), or that form is just plain wrong. That in fact, those requirements may not be so strange after all, that they carry more value than the ‘standard’ ones. I mean if there are too many special cases, perhaps they’re not so special!

Anyway, on multitasking again, I have been luckier than most in this respect, as I have had team leads who code and recognise the value of having dedicated time blocks for tasks. Just an observation methinks.

— Kamal