perspective programming

Team Balance

There’s a lot to be said for flexible work hours. They’re all the rage but they can be tricky when you need to collaborate on something meaningful. Maturing teams understand this and introduce “core” hours. That is, everyone -must- be in the same space for a set number of hours during the day; you get some flexibility to decide where to put the rest: on the head, or the the tail of that day. And then you have overtime….

An experienced team will undervalue overtime. The productivity gains are superficial and short-lived. The latent bugs and burnout issues which crop up down the line are way harder to solve. And that realisation, unfortunately, takes experience. Sometimes, more than you need. And sometimes, even when you have that experience, you doom yourself to repeat the same mistake under the illusion of end-of-the-world-pressure. But it’s not just the team you need to look out for; it’s also the individual within a greater team…

The output of any team is not merely the sum of individual contributions. It’s a collective output which is the combination of a number of quantifiable, but difficult-to-measure, actions: hallway conversations, peer pressure dynamics, inter-personal relationships, email:work ratios, extra-office activities… and on and on. For the most part though, a team result requires that the team move together at the same pace. Which is why they can either be really funky, or really frustrating, depending on your own personality.

So when you have one individual burning faster and more than the average pace of the team, you need to be cautious. Yes, leaders will put in more than normal: that’s what gives the team acceleration; impetus; momentum; drive. You have to start somewhere, sometime. But at some point, everybody should work roughly at the same pace. I.e. given a particular skillset and competence, the task should be completed by two different individuals on the team within the same business delivery time frame.

What happens when one cog spins more than the rest? For a start, that project plan (which you mostly ignore) gets even more muddled. The expectation for delivery timeframe changes (not just for current workload, but for future reference too). The inter-personal dynamics change (competition). The path of least resistance shifts and the workload tips in favour of the “Doer of More”. The rest slack off and you have this horrible elastic stretch in your execution plan. It will snap. 75% of the time. The other 25% of the time, it also snaps.

Now, you have to stretch that elastic from time to time. A balanced and measured test of that is a good thing. Shake things up and stir the pot. It’s healthy if controlled properly. Sometimes you get an unexpected organic boost of productivity which shifts everything into a neater gear: run with it. Recognise that and facilitate it. But don’t let it run out of steam “naturally”. The human spirit is strong: just watch the finish to any massive endurance test. People will push themselves beyond what’s probable and into a state of “cannot-do-anything-for-3-weeks-until-I-am-recovered”. So unless that’s what you want to achieve, nip it in the bud. And that takes a skilled project leader.

But as a peer, you are more intimately aware of when the pace changes. You have a responsibility to highlight that and bring transparency through to the fore. That’s what standups are for, right? Talking about the technical hurdles and objective progress of a project is EASY. You can go through 100 standups without challenging yourself or anybody else. Another path of least resistance. So how about using standups to bring attention to more important matters- issues that bug you in the soul but are hard to talk about?

Again, a good leader will cut short any ad-hominem or diatribe and schedule a time and space for it to be dealt with properly. The nice thing about using the standup for that is that you have the opportunity every day to voice your concerns. You even get to sleep on it for one night, to shift your ego away from the team’s greater good, before raising it.

Balance is not something we can always achieve on our own; despite our ingrained philosophies. That’s where East and West are remarkably similar. Both focus on the individual achieving his/her own internal balance and striving for that. But there’s nothing like pitching in and helping each other achieve balance.

You’re not walking on that tightrope alone. And yes, you work hard at making sure you’re not the one that causes the fall. But help others at the same time. In the wise words of Oogway: “One often meets his destiny on the road he takes to avoid it”

perspective Technology

HOWTO: Adopt Agile

I’ve heard the stories, read the reports, discussed and debated, disagreed and agreed, worked together and against each other; i think there may even have been blood spilled at one stage? I vaguely remember something about a keyboard and a dwarf… Indeed, if there ever was a word in the software industry which could raise the room temperature, it’s the little word “agile”.

HINT: If you ever find yourself listening to a techie and he/she/it is boring you with details from another universe and you don’t have a clue as to what they’re talking about (or what language they’re using even if it does sound remarkably close to your mother tongue), just randomly blurt “Agile!”- then stand back or run.

One of the concepts in agile is iterative development because iterative processes help achieve a goal efficiently by giving you the flexibility to change your trajectory as the goal itself moves. If you’re aiming at a goal that never moves, then this story is not for you. Also, check your goal for a pulse- it might be dead. Hence, it makes ironic sense to adopt agile in the same manner: iteratively. That is assuming you want to adopt it at all because if you don’t then there’s no point in proceeding any further. There are none so deaf and blind is how i remember the expression…

And the processes, practices and insights that agile opens us up to- testing, refactoring, pairing, reviews, continuous integration, dry, yagni and company- are also metaphors for adopting the very process itself. And even deeper, the metaphor for every software project should also be embraced for setting up your own company’s adoption of agile. Can you feel the power of recursion starting to make your head throb?

So think of adopting agile as a software project on its own and take it from there. Create stories like “get Paul* to integrate more than once a day consistently”. Get team players to estimate on the story. The team players in this case are those who actually want to get agile ticking along (volunteers). So it’ll probably take 2 weeks before Paul gets it right. Maybe if Igor* took the story he could “convince” Paul inside a week? Create your storyboard, organise the flow, derive a project plan, split it up into more iterations (if need be)- the usual. Then “code”.

Having trouble with Paul? Pair-up with someone. Tag-team it. Refactor. Check in your working “code” regularly. Review what’s been done. Write new stories. WARNING: You might actually start having fun. Role-playing is an essential survival trait of almost every developer. It’s addictive and to pretend that you’re actually the software is going to be a little mental for some, a little esoteric for others but hysterical for a geek. Oh, and don’t be surprised if your developers start to get a little carried away and come dressed as hexadecimal numbers to work. Just keep a straight face and say “Ah. Good morning, 1.6A09E667”.

On the serious flipside, when you start to setup a project plan for adopting agile in this manner you also get to eat your own 0xbaadf00d; practise agile more; refine valuable skills; learn lessons; incorporate it into team culture; get an empirical idea of how close you are to hitting the mark and have a working team at all times (this is most serious). All the feel good fluffy things you want to hear.

And on the negative, less fluffy, pessimistic , dark and evil side of things, when you start to overrun your estimates badly on a lot of stories, you also start to get some really good feedback on when to can the adoption and/or start again or try a new tact. Ok- that’s actually good news too. But how much you try will depend on the strength of the character flaws in your project leader.

And before you know it, you’ll be miles away from being the perfect agile team. Indeed, just like software, there’s always one more feature you can add or take away. There’s always that one routine that can be a little better. And over time, you need to make changes that help you stay relevant and marketable and profitable. It’ll always be perfectly imperfect. And so you keep coding, creating and evolving something even more beautiful (and useful) than you ever imagined in your wildest electric dreams.


Piracy is NOT A Crime*

I did not see one this coming. Under South African law, piracy is not a crime. Contrary to all those ads on the DVDs and the big screens sponsored by the DTI and all the talk and all the hyped media…

I’m no lawyer and like most people rely on the messages that are published by authorities to understand what we can and can not do. So my boundaries are then subsequently defined for me when I choose to assimilate those messages into my day to day life. It seems that one of the big lies has been: piracy is a crime. Ok, maybe not a blatant lie. But they certainly did their best to link the criminal element in. You wouldn’t steal a handbag….?

But all is not what it seems.

It does appear to me as if the spin doctors were doing their best on this one to, well, make or save a buck. And if there’s one thing I learned a long time ago, if you don’t understand who/what/why of any situation… follow the money.

* not a crime for personal use only. not referring to them that import thousands of pirated copies and then bootleg them on the street corner. that IS a crime.


HOWTO Do Software

The expression “software is hard” (a quote from Donald Knuth if I’m not mistaken) has seen a lot of mileage (yours truly contributing my fair share) over the years because of it’s simple truth. And in that, we’ve all searched and found (or not) some or other holy grail of methodology. And then the methodology wars began…

And with each new spin, a new skirmish emerged on the radar. Even some of the the tool-chain manufacturers got involved, either creating their own style or methodology (i suspect largely to suit their product rather than the process) or adopting their product to try and encompass the latest and greatest in fashionable methodology. Much ado.

Now software is both art and science. And as such, you need a healthy dose of both to get it right. The art demands your imagination and creative skills; the application of your emotional quotient and your ability to think beyond the four-sided. The science demands much the same plus discipline. Art, too, demands discipline (find me a great writer, painter, cartoonist, graffiti-artist, musician who did NOT practise and hone his/her ability each and every day- for hours each day). Art and science are much the same. Discipline is but one of the common threads.

Discipline to sit down each and every day, for hours, and get it right- get it perfect. That doesn’t mean just hours of random throwing paint at the canvas or the random plucking of guitar strings (which is my forte, by the by). And what about the scientist? Does she spend hours each day in the laboratory throwing random chemicals together into a test-tube to see what might happen? Maybe once in a while, that kind of activity is fun- but not a primary activity.

No. They all set themselves down each day, both scientist and artist, and constructively engage their brains, and think for themselves about what they are actually doing- or going to do. They know before the experiment or song or painting is completed- what to more or less expect. Sometimes it doesn’t turn out that way- and the results are either surprising or horrendous. Sound familiar? But by and large, it’s predictable- and it should be. Software is no different.

How you get there, and which methodology you use is largely irrelevant (i say largely, but you need to read the legal copy disclaimers in fine print carefully); as long as you have discipline. Following a set pattern so often that it becomes part of your autonomic nervous system is key. There’s good reason to do it, especially when you add in the one thing that distinguishes software: deadlines. Although, I am sure that in this day and age, professional artists and scientists suffer the same. Deadlines make the job more interesting- and the need for discipline even more critical.

A brief observation of any professional field where life and death are important will reveal the stand-out-in-your-face notion of REPEAT. In fact, it’s the only way we actually ever learn anything. You repeat the excercise over and over again (ad nauseum some might say) until you get it right blindfold. Why? Because when there’s a deadline, you go blind. And the more impossible the deadline, the more blind you become. You don’t have time to think- just time to do. And you need to make sure you are STILL doing it perfectly.

So, HOWTO Do Software. Pick a way. Find a way. Develop a style and method of delivery that embodies rational scientific reason to justify the “why” you do it that way. Don’t do something or end up doing something “just because it’s the way we do it” and not have a valid reason and purpose behind the behaviour (and I’m afraid if you don’t even recognise that, your opinionated delivery is just going to be that- opinionated). Add in your own artistic flair- but above all- be disciplined about it. Not just off beat, whacky, eccentric, random or out there. Notice i said “just”. Which means you can still be off beat, whacky, eccentric, random or out there- just be disciplined about it. Oh- and write quality tests 😉

perspective Technology

Software Guarantees

It’s a long time coming: consumer protection for software. And it’s a good not altogether bad thing. How much software out there promises the world but delivers nothing but a world of headache? Of course, the devil is in the details and how they go about enforcing that is going to be interesting. Can you imagine the legal copy? Of course, this opens up the world for computer forensics in a big way. We might even get a new show: CSI Brussels, the Bits-n-Bytes version. Ha.

But from an engineering perspective, this kind of move will most certainly sift out the hype from the functional (and create more of a different hype) and all the war around the best technology might abate (while the war between lawyers rage) so that the job can just get done by those actually doing the job and knowing how to do it (which, by this stage will not be many). It also means developers will choose their tools more carefully and with more consideration and be less prone to just adopting the next best thing just because it’s the next best thing. Which, in turn will impact the software tool market (probably negatively though). Who’s going to write code to interact with a service (or even allow interaction) if you got no control over how the other end of your integration works and you could possibly get sued for thrice more than you earned on the job. Imagine the insurance?

Of course, i’m assuming that the implementation of this kind of policies (or others related to it) is well though-out, fair and just 🙂 The evil side to this kind of policy is just too staggering. That’s something for the budding authors (of CSI) out there to write about…


Annoying Software

One of the funniest things i read this morning… or maybe it was the tea?

“And yes, when I ask to exit the software, that’s because I really want to, not because I’m having a crisis of doubt.” (The bold is my emphasis)

LOL How many times have you joked about this? Are you really really really sure you want to exit? Really? For sure? Think about it carefully, because if you close me now, and you didn’t mean to, you’re going to have start me up all over again. So, are you sure you want to exit?

And the irony is, whenever i create an application where i don’t ask the user “Are you sure you want to <INSERT REQUESTED_ACTION HERE>?” after they explicitly clicked on the button to execute the aforementioned REQUESTED_ACTION, it feels like commiting a crime. In fact, i even had a user the other day log a “bug” saying: “Isn’t it supposed to ask me if i want to do that?” Priceless.

Btw, the quote is from an article on zdnet

Business Rants Technology

IT “Industry”

I say “industry” but there’s no real regulation put in by the government (at least here) which keeps the industry in check. For one, it’s not illegal to provide IT services or build software without a licence, while in more established industries, it is illegal to, for example, provide medical, financial, engineering or manufacturing services (where people’s lives are at risk) without a licence. Anyway, that’s not a formal classification or rule, just an idea that appeals to me. Why the necessity to make the distinction?

Over the last decade of building software, i’ve seen a fair share of hair-brained ideas. I’ve also seen some brilliant ones. What i haven’t seen much of though, is brilliant management. I’ve seen some, but these generally come from the business-oriented bunch who just happen to end up in IT; very rarely from tech-savvy management trying to keep a business going. In fact, most of the time, tech-savvy management who try to run their business without business-focused partners end up either working way too much overtime (work = life =work) or going belly up. Somehow, there exists this hype perpetuated by punctuated newsworthy stories of geeks-in-a-garage-cashing-in. So if they can do it, why can’t we? ‘Cos not every story turns out that way.

And particularly software. Manufacturing, distribution or sales, whether it’s IT or food, is the same thing, mostly. That is, the science and art of management has been established and the discipline is well understood. Software, on the other hand, doesn’t fit the mould. Yes, it’s plain manufacturing, distributing and selling, but therein lies the rub. You approach it with business fundamentals, and it works, but if you don’t adapt some of those implementations; you get left behind- and quickly. You toss out the fundamentals in order to keep up; you get dropped behind- even quicker.

As an example, my last company just liquidated. There are lots of different stories as to why, how, when, where or who. Bottom line, no more business. I can only comment on the software aspect; not the rest of the operation. So the only thing i do know is that it was very tricky getting the software strategy just right. Everyone pushed and pulled and chewed on this one all the time trying to get it to work. Maybe, with a little more time, it could have worked out ok in the end? Next time 🙂

More evidence supporting the notion that “software is hard”. And it makes me wonder how different things would be if you had to be officially licenced/qualified, by law, to operate in providing a software writing service. Not a fly-by-night programming course. Not a dummy’s guide to programming. Something professionally trustworthy and legally accountable. I wonder just how far would that go towards stabilising the “industry”? Make it more reputable and have governing bodies presiding over fair exchange between vendors and clients; also ultimately curbing the number of software businesses that just don’t make it.

Neh. Where would we be without the hype? It’s part of the magic of this little world 😉

Business Rants Technology

Crack My App

What do you do if someone asks you to do something illegal?

Of course (and i do sincerely mean and hope, “of course”) the first response is to just say “No”. But does it end there? Maybe it depends, maybe it doesn’t?

Well, I was asked by a company to crack some software. Everything was totally illegal and i declined, of course. But as i sit here thinking about it, revising my study module on business ethics, i wonder if just declining is enough? Should i actually report it to the authorities?

If someone asked me to go steal a car, i would definitely report that to the police, after carefully and probably politely removing myself from the company of the requestor.
If someone asked me to steal some money, even if it was money owed to them, i think i would also probably alert “someone”. But if someone asked me to crack software (because i can since i’m a programmer- or at least, that is the assumption), whom do i tell? Do i even need to? Nothing illegal has happened.. but just where does the line end?

Grrrr. Why do idiots want to crack stuff anyway? Just play by the book and it’ll be easier for all of us 🙂

Rants Technology


Much has been said about quality of software, and even more attention has been given to it. Further, a lot of methodology, and general how-to-do-stuff from project management to code implementation, even design and testing is focused on quality, including the ubiquitous “best practices” and framework collections out there. But then it struck me. All the software i “actually” work with is buggy.

It’s good enough, get’s the job done and i live with it, mostly. And like any good web-theme, the software will be replaced (read: recycled) soon enough, so why the big fuss about quality anyway?

If you got a good idea, get it out, sort the bugs out later, and if your idea is any good, you’ll break even before you manage to iron out most your major bugs, by which time it won’t really matter anyways. Uhuh, i hear a lot of “but that won’t work with real business software”. Really?

How many projects you code, pick up, migrate, port, patch, fix, debug or rewrite because business was complaining that they were (now) “too buggy”? But they were using them, right? And probably surviving pretty well with the “broken software” since now they can afford a software team to code, pick up, migrate, port, patch, fix, debug or rewrite. And the job would be done “ok” except that now, quality is an issue.

Reactionary management has a lot to do with it, but it leads astray and breeds a buzz which forges a plethora of blogging on delivery quality, all under the guise and good name of “it’s what the customer wants”- which they do. But not actually :p

When last did you use bug-free software to pay the rent?

Disclaimer: naturally, this is not a call to “down with quality”, or even “forget about tests”. it’s just a very radical and extreme (for me, at any rate) reflection on the focus we give to quality. For one, i groove on quality 🙂 while at the same time i can secretly admire that *some* manage to manage buggy software better than they can actually write it 😀