Author: bryan

Time Is A Resource

We started off our project with the recommended 2 week iterations. And this worked well until the system grew to a maximum capacity. That capacity being defined by the amount of resources available to the project available to satisfy the requirements. At this point, it became neccessary to introduce a reflection period between each iteration. Running iterations back to back didn’t allow sufficient time for the business nor the technical teams to absorb progress adequately. Interestingly enough, the number of bugs found in QA was an indication that we had reached this point.

The bugs were either a result of loosely defined requirements being misinterpreted [things were happening too quickly] or by technical implementations being delivered so quickly that logic was being duplicated, not by means of bad development processes, but because there wasn’t enough time between successive iterations to reflect and overview the system to see where it was headed.

After introducing the mandatory reflection period between each iteration, it allowed both the business and technical teams to catch up with a rapidly evolving system. After a while though, the added reflection period, which contributes to the capacity of a project, became insufficient in itself to deal with growing system. We needed another mechanism; in short, we needed more resources.

The reflection period turned out to be a resource which we used effectively to facilitate the more well known resource concepts: money and people. At least, the resources which we perceive to have more control over. For some reason, Time is still perceived to be outside our control.

Our next strategy was to change iteration lengths. Afterall, we are Agile, aren’t we?

So now we’ve adopted iteration lengths from anything to 1-3 weeks, depending on the business urgency of requirements and the volume of requirements. This iteration length is established by the business lead since they are the ones that need features by a certain date. And then, following our standard practices, the technical team determines what can be done by that date. This might seem a strange way of working for some and hard to grasp since immediately it will start begging a lot of questions. But it does work [for us].

This variable iteration period works well and allows us huge dynamic advantage as well as keeping things interesting without losing the much needed routine. The reflection period stayed and became a percentage of time of the iteration length. For now, we’ve adopted 25% as a guideline. As with most things, this is monitored and flexible, but not to the point of sacrifice.

More recently, we’ve taken the concept a little further by not starting iterations until the requirements are, by guess-timate, at least 80% accurate. This means now that both our start and end dates for each iteration are driven by business readiness.

So, in projects where budgets are limited [anyone working with unlimited funds?] and people are expensive [ramp-up costs plus hourly rate versus value to business over time], Time is the other resource you can play with. Using variable iteration lengths and reflection periods and only starting when the problem is sufficiently defined are just some ways you can manage your project more effectively…

Categories
Technology

I Love My TestHarness

now wouldn’t that make a great bumper sticker? 😀

again, yesterday, i experienced the fullness of my beloved test harness. as it always happens, business requirements change; dynamic market pressures or product discovery over time dictate that change is required. now whether you’ve spent 6 months designing before coding or spent 6 months designing through coding [implemented code IS the design], how do you evaluate the impact of the change accurately? how do you go back to the hand that feeds you and estimate the cost of change with confidence [which impacts on a marketing strategy and promise] and maintain that near-perfect delivery track record? and then, how do you know, for sure, that your implemented change doesn’t inadvertently break some other part of the system because the system is now so huge [increasing feature set over time] it’s getting near to impossible to keep it alltogether in one moment?

welcome the testharness!

it was so quick to implement the change [fully tested on it’s own of course] but then integrate the new module into the existing system… the next step was to figure out: where to begin with handling all the other intelligence that relies on the old structures and is impacted by the new structure?

ran the tests. red bar with breaking intelligence over one primary area. there were one or two adhoc modules that were affected. no sweat. the beauty was that i din’t need to comb throught the system to find them. i let my system tell me and in doing so saved myself a load of cognitive energy. now that the buggy areas are recorded i can fix one test a time until the bar is green and walah! 😀

there was *life*, allegedly, before a test harness and now then there’s life with a test harness. i cannot remember what software development was like before. i just know now that more than ever before i truly passionately enjoy my craft! [which also happens to pay the rent ;)]

Don’t Panic

It’s no wonder the Hitchhiker’s Guide to the Galaxy was such a bestseller with the bold words Don’t Panic sprawled on the cover. Successful software development shares this same sentiment. Don’t, under any form of duress, panic. Even at the threat of having your livelihood cut short.

I suppose it was TDD, Agile, XP, and all the usual suspects that, over time, instilled within me the confidence to not panic under any given situation. Well, to be honest, most situations. And within software there is no shortage of situations to induce panic right from the business through to the development layers. Polytricks *sic* included.

Unrealistic deadlines, scope and resource availability to get the job done; team dynamics and psychology; technical hurdles; environmental and infrastructure glitches; all these going wry at the wrong time, and if it does go wrong it will be at the wrong time, can introduce panic into any team via one or more individuals. It’s exactly at this time, that the team/product/project/company/individual is defined. What you do at this critical point is what ultimately defines your commitment to methodolgy, principle, philosophy, vision and holds you accountable for all you’ve said and done in moments where panic was not lurking.

Yes, it’s easy to say all the good stuff when there’s no pressure to deliver. Stick to your guns when there is pressure to deliver… IF by Rudyard Kipling comes to mind… and you’ll be a programmer, my son!

The most important reason not to panic for me is: whatever it is that makes you successful, you must never forsake. Especially not for panic. So if it’s UML, TDD, waterfall planning, Agile practices, pair-programming, guess-timating; and you’ve identified exactly what it is that has made you successful; don’t drop those practices because of panic. You then start playing a game that you’re not used to with rules you can’t play by and immediately you’re disadvantaged and you will be beaten simply because Panic has more experience than you playing the panic game.

Yet it surprises me how time and time again we revert and tred underfoot those very things which work for us, all because suddenly, in panic mode, we can do things better by doing them a different way:

don’t write tests
skip QA
release untested
don’t run tests
don’t estimate how long it will take to fix the bug
cut a corner anywhere, anyhow, whatever you do, just do it quicker.

And somehow, all these mandates replace and more surprisingly, convince a development team that they can operate better without any of their usual safety nets because Panic will make sure that their work is of superior quality than the work produced with no Panic.

Yet, sadly we know this is not true. Yet we fall into the trap of not walking the truth.

Panic fixes, not tested, not documented, not QA’ed are superior? If that was so, why don’t we write all our code under panic 🙂 which, actually, is a reality for some teams.

And i suppose that is where some of the problems lie. Some developers are too used to writing panic code that they have little experience of code quality outside Panic; and therefore cannot compare their current quality to anything else. So as long as there’s Panic, there will be good code. Does burnout mean anything to you?

I prefer not to Panic. Keep calm. Relax. Whatever the reason for panic, there’s always a plausible explanation. Besides, the code you’ve written and the bug you’ve just deployed 🙂 is just doing what it was programmed to do. All that’s required is a change. No Panic. Panic, and your change introduces other untold changes…

Until the next panic then… 🙂

Tradition vs Logic

Thinking a bit more about those hard to break habits of code, it really got me to thinking about why some habits, or really traditions, are so hard to break. Some of those traditions include:
The PrivateInstanceVariableMandate, discussed earlier.
Then there’s the SingleReturnStatement which enforces the following:


function boolean foo(int args) {
  int result = -1;
  if(0 != args) {
    ...do something...
  }
  return -1;
}

which can really be simplified:


function boolean foo(int args) {
  if(0 == args)
    return -1;
  ...do something...
  return result;
}

of course though, we’re committing the heinous by having multiple return statements in the same function. no explanation or logic other than that’s the way you must code. and i have heard it impressed upon soo passionately, it was frightening.

not to say that the alternative is better, that’s another discussion. it’s just that tradition is so entrenched that questioning it is out of the question 🙂 and when you’re still learning, these dogmatic rules become so strong that later in programming life, it’s hard to change.

but i guess that’s no different from other avenues of life-learning…

any other hard to break traditions out there which defy logic and which have a neater alternative? and more so… when you do use the alternative, how many eyebrows are you raising?

PrivateInstanceVariableMandate

While reading through Quality-With-a-Name, which by the way, is a good read, there was point of design interest that James Shore touched upon which i really struggle with sometimes. It’s the PrivateInstanceVariableMandate. How often have we ended up with a class which has the design


class Foo {
  private string name;
  public string Name {
    get { return name; }
    set { name = value; }
  }

now this kind of class i usually write by rote. Then i’ll pause for a moment to consider the blasphemous…

class Foo {
  public string name;
}

at which point, i’ll quickly repent and stick with the memorized version but somewhere i know that i’m just not doing a good job of good thinking.

worse yet there are times when i start coding, and in a momentary lapse of reason, the result is the heretical design! then after all is said and done and the check-in is about to be committed, i’ll be reviewing the code with a sense of guilt.
o, the shame! should my college lecturer saw me now…
woe is me! should my peers review my code….

now why does it feel so bad to take the “shortcut” when all my reasoning and powers of logic convince me that there is no real difference between the two designs? except maybe a few lines of code. why is so hard then to break with some hard-lined traditions?

Shooting it straight

Abraham Lincoln, or so the story goes, once asked: “How many legs does a cow have?” to which the reply came: “4”. President Lincoln then asked: “Now, if you take its tail and make that a leg, how many legs does it now have? 5?”

The software cow, by a wide stretch of the analogy, is based on deadlines, particularly code closures and releases. But by making the code closure date the release date, how many deadlines do we now have? With a cow, any cow in fact, it’s quite simple. A tail can never be a leg, even if you call it a leg. And it should be the same with software too. A release date can never be a release date if it’s actually a code closure date. Call it what you may, but it doesn’t change the reality of what it is, or isn’t.

Now, our real challenges take shape before we, the humble cow makers at your service, have even considered all the complexities of the legendary promised cow. The schedule for the project is conceived in advance by declaring one cow, four legs and a tail. Using graduate-grade financial analysis, and some logarithmic calculus for the more eccentric, deadlines for a functional cow are
established. Can moo. No chewing of the cud, but there’s 4 legs and a tail that will go “swoosh”, but only in version 2. From there, it’s up to the cow builders to deliver this promised bovine, on time. Now without taking any digs and waxing nauseously over the same age old arguments about who’s responsible for not presenting the 4 legged, tail-swooshing, cud-chewing beast on time, how is an idyllic XP-orientated world supposed to operate? And this time we’ll work forwards.

Build a cow. When you get to the part where it’s got 4 legs and a tail (don’t worry about the swooshing just yet), close the code. Based on that, testing can be scheduled; deadlines and release dates can be accurately planned. The nice advantage of living life forwards like this is that you can milk your cow at any stage. Simply set a code closure when you want to start selling. If at the time of wanting to sell, the cow only has two legs and subsequently walks around in circles, it does so by design. If you don’t think that will sell and want the 3-legged limp, but a good limp at that, then you have to wait for the feature is estimated before setting a code closure. A full 4-legged trot takes time. It’s impossible, no matter the methodology, to know upfront exactly, to a tee, how long any complex software will take to build. Which is great because as you build, you want the ability to adjust to constant change. Unless of course you want Retro-Cow, conceived in the 80’s to live in the 00’s because you couldn’t change the plan en route. We do have estimates though, but lets not forget the obvious. A 4 month plan cannot be real if the work is envisioned only 2 weeks at a time, and story should not be more than 3 days. You may have picked up on my use of the word “should”. What we tend to do outside of this resembles little of what XP is.

Plan ahead, line up the fence posts and work backwards from there. And being current, thus ensuring survival, demands constant change but without compromise on the boundaries, code closure and release dates start spiraling closer together. The full-bodied moo, plus some more moo, but all in the same timeframes. The knock-on effects of this I could however wax nauseously over for many moons. I’ll endeavour not to but team moral, duress, waning quality, stimulant dependencies, indecision and fear are just a few things bursting to mind. Everything we work so hard to establish and maintain become ‘ideals’ rather than the ‘reals’ they were a day before.

XP in development is only as good as XP upstream. It cannot just be a development methodology on its own. If the objectives that drive and sustain the business are not tied into XP “development” principles, how solid is the foundation for implementing XP? The real champions of XP have to be those that build the very foundations which drive and sustain the business. They’re the ones who have to be the most tenacious and ooze XP honesty, courage and maturity. They should be the real defenders of the methodology for only as much trust as they put into XP will water the branches. If our business strategies are not tied into XP, what hope do we have of development ever being based on XP? What’s really challenging is calling development XP but not living it.

It’s like being invited to play croquet on Sunday afternoon with the Queen, only to be confronted by 15 menacing All Blacks doing their hukka while you clutch ever so confusedly onto your bow tie wondering how painful it’s going to be. If we call it XP, let’s do XP, but the roots water the branches; never the other way round. But if we’re not going to do XP let’s call what we do something else so at least we can come prepared to the task at hand. What’s more important than any one methodology is that everyone agrees to build the cow the same way.

Categories
Technology

It’s all in the estimate

Estimates form the basis for all software projects. In fact, estimates are part and parcel of our daily lives. We live, plan and act by them. Our expectations are met or shattered based on the estimates we feed into our lives.

Buying food, you might estimate before you set out how much money you need, how long you think you might be and plan supper, a night out, a telephone call based on the estimates you give yourself. When life goes according to our estimates, we’re happy. Everything is running smoothly. When estimates are wrong, we adjust, but sometimes, the ability a bad estimate has to flap it’s wings and spiral out of control can be deadly. Especially for a software project.

Based on estimates, business programmes are set in motion. Budgets are approved and marketing plans are established. The length of the estimate is largely irrelevant. What’s critical is its accuracy. When projects, and hence people’s careers, lives, finances, lifestyles, families, are on the line [ok, maybe a tad dramatic :)], an estimate has the misfortune of not being taken too seriously on one hand, or far too seriously on the other.

Taken too seriously and the time to estimate can be as long as the time to do. Not taken seriously and the time to do is incalculably longer than the time to estimate.

And because estimates can be co critical, it does make sense that the right amount of energy
be invested into getting them as accurate as they need to be, weighed against the cost of getting them too accurate. No solution strategy, technology or skill set is going to set you up professionally if you don’t know how long it’s going to take you to do something, do anything. If you don’t really know how long it will take, it does imply that you don’t really know what you’re doing. And if you establish a trend over time of not delivering when you say you will it shouldn’t come as a surprise if your services become undervalued.

Of course, you can always “buffer” your estimates and play it safe. But in a dog-eat-dog world where the ubiquitous “5-minute solution” marketing threatens your chances of being awarded the contract [or the glory- however inaccurate those 5 minutes are], buffering can be expensive.

Considering the risks, together with the cost of not being accurate, it pays dividends to be more boldly accurate. And to be more boldly accurate, it takes time invested into getting to know your weaknesses. It takes being honest with your progress using feedback mechanisms that might hurt your feelings. It requires that you get better, not just at what you do, but at how you do what you do.

Categories
Business perspective Technology

Beautiful Programming

With a mission statement which includes phrases such as creating beautiful software and a focus on beautiful people, it can sometimes be hard to follow such a mission if the very objective, beauty, is hard to materialize.

It has been said that beauty is in proportions. The moment you start emphasizing or leaning too heavily on one concept, you start to caricature the concept and fade on beauty. Beauty is all about holding the right proportion at all times.

Beautiful software does not waste features, but has everything you need. The interface is not busy but practical. Its efficient and natural, but cruising through complex problems. The code is not bloated and not cryptic due to code line famines. It has the right proportions. Beautiful people are controlled but not retentive. They are passionate but not sentimental. Expression is a skill, not a habit. Focused yet continually thinking out the box. Pushing boundaries and pioneering but never falling off the edge, beautiful people contain the right proportions. Bringing the two together is indeed a mission statement, but requires more mission and less statement. And to achieve this, we use the inaptly and irony-burdened name Extreme Programming.

In its essence, it aims to contain proportion, never to focus on the extremes. The right design, but simple enough and agile to tackle complex systems. Estimating to cater for business forecasting and survival but not allowing dogmatic routines and methodologies to dictate. Indeed, a minefield of contradictions when you lean too heavily on the one concept to the neglect of the other supporting principles but by achieving the right proportions and you attain beauty. Perhaps we could reconsider the term Extreme Programming (afterall, its laden with cliches and prejudices) and look at the ways we want to work and what we want to achieve. And never forgetting, most importantly, how we want to achieve it. Perhaps, the way we implement our mission is more suited to the title Beautiful Programming because beautiful software, created
by beautiful people can only be created in a beautiful manner.

Categories
perspective Technology

The Agile Debate

There are two main schools of software development: those that love agile processes and those that don’t. Of course, there could be those that couldn’t care either way….
And both have very convincing arguments and both can be as passionate about their own [dis]beliefs. But just as soon as somebody hails a solution to our problems, there’s already another gang crying that the solution is the problem, or is the bigger evil of the available problem domains.

Wether you like agile process or not, benefit from mechanics of pair-programming or not, have had your ass quite literally saved by TDD or not… there will always be a process that you follow, however loosely [or not] defined and [not-so] obvious to the rest of the world. It is amazing how the n-schools of thought justify their existence by the apparent shortcomings of another. This is no surprise since the world operates in this fashion. Democracy rules because of the evils of autocracy. And vice-versa. There are not many, if any, systems which are self-justified. Agile processes rule because of the shortcomings of traditional development processes. Traditional development approaches rule because the alternatives don’t work. This is the mindset that pervades the path we choose.

The irony is is that if it works for one, it’s because it just works in that time and space for that collective group of people. Does it mean that it will work for another group of people, on a different project, with a different skill set and varying group dynamics? Of course, you’re welcome to say it will. You can also say it won’t. In other words, you can speculate. But no amount of speculation will justify how right or wrong you are about another group’s implemenation [interpretation] of the same principles.

What works for one project works because the people on that project make it work. What doesn’t work, simply doesn’t work. None are so blind and deaf… And with methodology, nothing will make it fail as much as those who don’t want it to succeed.

Categories
perspective Technology

Crossing the Line

There’s always a line waiting to be crossed. Morally, technically, physically. With whatever we do, or can do, there will be a line. And some of us will cross that line just because we can. It doesn’t mean though that we should.

We can cram a plethora of features into any software product. Doesn’t mean we should.
We can add layers of indirection into our architecture to push the boundaries of decoupling. Doesn’t mean we should.
We can implement [insert pattern name here]. Doesn’t mean we should.
We can deprive ourselves of sleep and turn a 4 day project into a 2 day delivery. Doesn’t mean we should.
Just because we can, it doesn’t mean we should.

Too many decisions are implemented based on what we can do. Usually there is some discussion about what is possible and what is not. Wether or not it makes sense, is not beside the point but can certainly be diluted by confusion amidst emotional rhetoric. And then after all is said and done, there being no obvious agreement, a public opinion poll is held. Oh behold the saviour of our modern thought process: public opinion. It has been said that public opinion is no substitute for thought. Behaviour beg to differ.

Of course, the problem with lines is that we often don’t know what the other side is like or where that line was actually drawn. It’s only once we’ve crossed it, do we realise that we’ve crossed it. At such times, realization and prompt action can help alleviate any problem caused by being on the wrong side. It does take some courage; different to bravado which is usually what crosses the line in the first place. Itself, another line: bravado and courage.

Recognising where the line is and if it’s worth crossing is a valuable skill. It’s the difference between profit and loss. Value and gimmick. Genius or just clever. Working hard or working smart. If there’s one soft skill your team can encourage, it’s line detection.