Month: April 2006

chicken or the egg? the question applies to just more than poultry, or breakfast, depending on which you think came first. which comes first, commitment or results?

in order to succeed at anything, we need to be committed, but often we first want some guarantee of result before we want to commit to anything. which we choose to come first, will depend on which area of our lives we’re talking about. but should it be that way?

starting a new job, for example. do we commit to the new job even if do not know what the future will hold for us there? trick is, if we don’t commit, the job will probably never work out anyway. at the first sign of trouble, the unsteady and doubting foundation which we set for ourselves on embarking the journey doesn’t offer any support. if anything, it will convince us even the more to abandon the cause. had we committed from the word go however, any sign of trouble will be percieved as opportunity to grow. results and success are inevitable.

it can be argued however, that signs of trouble do represent real trouble and we need to be cautious in not overcompensating by ignoring any “signs”. but this is not the topic at hand. i do concede that not everything is or should be an opportunity to grow. but the focus of this piece is the relationship between commitment and success.

extending the job commitment scenario, let’s look at relationships. do we commit to a relationship, not knowing what to fully expect? And thereby, because of our willingness to commit, the relationship succeeds and overcomes all challenges? Or do we wait for the relationship to show signs of promise on its own before deciding to commit? Question is: can a relationship show any sign of promise just on its own without any commitment by both parties to, at the very least, for example, commit to making each other a priority in their respective lives?

and then in spritual matters. does our religion have to offer us some sort of return-on-investment [time, money, emotion] and show good future prospects before we decide to fully commit to it? or is it possible to commit to it first, and in doing so, live and breathe the principles that, hopefully, lead us into a richer awareness of what it means to truly be alive?

so where does commitment come from? passion.

passion drives us to making a commitment. it won’t neccessarily sustain our commitment but can ignite from time to time [i’m referring to voluntary and not that fear-based or co-erced commitments]. that passion or desire [love?] in the moment of the commitment gives us the courage to make the commitment to things unknown, or rather, not yet known. but with the commitment in place, results and success are inevitable.

so where does passion come from? the heart? gut feeling? something needs to spark up and give rise to passion which will fuel the readiness to commit. and then there’s that other bit of trickery that goes on: that passionate feeling doesn’t last forever. the sparks fade relatively quickly, as sparks do. how do we make it linger through the range and bombardment of emotions and choices we face each day?

sustaining a particular emotion over an extended period of time requires a combination of physical, chemical and cognitive energy. how we manage to do that is each to our own little secret to living happy lives. and then there’s always this to consider: a passion that fades in the face of adversity- was that really a pure passion [versus fancy] or is it just passion under testing and how important is it to you [truthfully] to pursue?

maybe why we give up so easily on tasks, paths or journeys we set for themselves is because we’re choosing the ones that aren’t dripping with passion. and because there’s no passion, we don’t want to, we can’t, commit. and because we’re not committed, we fail when we hit a rough spot.

conversely, if we choose journeys of passion, we will commit to them 100% and through that commitment, we’ll reach the levels of success possible within that path. be it job, relationship, spritual or communal…

big problem is that this statement is itself a very absolute statement. so if you hold to the “absolute” truth that “truth is relative”, you’re in a bit of a predicament and you got some explaining to do. maybe your persepctive of the truth is relative, but that doesn’t change the truth itself.

if truth is absolute, well then there’s no problem then, is there. what is the truth, is the truth for everyone concerned. deciding of course, what exactly is the absolute truth is, is another question altogether.

i’m going to stop there before my head explodes.

For the past 2 days, i’ve *finally* had the opportunity to work in both C# and Visual Basic simultaneously! It might seem like quite a lame goal, and yes, it probably is. But it was interesting none the less, to dynamically compare the two languages, and bonus- getting paid to do it- ie not doing it at home after hours as part of research or interest.

The functional library was written in VB [WebChart by blong] which didn’t quite have all the functionality we needed. But it did provide a good fit. On the negative side, it didn’t come with a set of test suite *shock.horror* The rest of our web application is almost entirely C#.

The day arrived on Monday when WebChart needed to mature and we needed to do the moral thing. Add tests. The test code itself was written in C# and this was the perfect platform to code simultaneously without “looking” for an excuse, erm, opportunity to truly compare the two languages.

After a few days of implementing in VB.Net and then directly using the implementation from C#, i still prefer C# but definitely have less of an aversion to VB.Net. I’m glad to see VB and array indexing has come of age. Yes, but not just reading about it- actually using it. There’s something about us programmers ‘cos we don’t trust documentation; no thanks to years of bad SDK’s. We only believe once we see something in action, and that, in production on our system.

The { } are by way FarMoreEfficient than the End … statements. More readable and when you’re looking at nested loops, the

For Each ...
  For Each ...
  Next
Next

was not as easy to find as

foreach(...)
{
     foreach(....)
     {
     }
}

And using [] for arrays/lists is nicer than () which usually refers to a method, i mean Sub

Etc.. etc.. And many before me have waxed lyrically about the two languages, but i’ll stop here.

If anything, it provided a good mental workout jumping between the two so dynamically. But there were [lost] times when i stared at the screen wondering why the *&%#! the following

Private Function GetLegend() As SortedList
   int index = 0;
End Function

would just NOT compile 🙂

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…

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… 🙂

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?

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?