Passion, Commitment & Results

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…

Truth Is Relative

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.


DataBinding on ASP.Net

After consideration from a previous post, i decided to boldly test my new class designs by making those private instance variables public. Beyond struggling against my own niggles, i discovered that ASP.Net doesn’t like breaking PrivateInstanceVariableMandate either. Consider the DataBinder for example.

In your mark-up code, a “typical” repeater section might look like

The DataBinder.Eval however only evaluates properties of that object. Public fields [class variables] are not properties and so breaking with traditions and trying to make things simpler, proved to be more complicated down the line [on this framework].

With a little co-ercion, it’s easy enuff to write a FieldBinder

to allow code such as above. All of a sudden i can access fields and it’s all good. Now the pro’s and con’s of introducing FieldBinder into the system can be debated at length, but the beauty of this insight led me to an even more interesting possibility.

There are times when real-time data associated with an object needs to be retrieved. Making the function a property, in a no-argument case, again, is a design preference but can lead to problems since the property EmailCount conveys a different sentiment to the method GetEmailCount(). The method, for me in my current project, implies that more work is done to retrieve the value than simply looking at one of the already present values. So i really want to keep it a function but can’t bind to it using DataBinder.

Extending this idea further, you can overload FunctionBinder to accept specific parameter types or arrays of objects for the function arguments. How you do that, well, that’s your decision…


Mixing It Up

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 ...

was not as easy to find as


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 🙂

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…


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) { something...
return -1;

which can really be simplified:

function boolean foo(int args) {
if(0 == args)
return -1; 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?

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.