Simplest Thing

An *agile-biased* blog would just not be complete with at least *one* article on TheSimplestThing… so here goes:

I has occurred to me [and no doubt, countless others] that after all that has been said about TheSimplestThing; there is no simple definition. The irony does not escape my sometimes blindingly slow wit, but simply put, simplest thing has not [yet] been defined with the simplest definition that can be agreed on. If simply defining a concept is not clear, how can it even be implemented?

Fortunately it seems that TheSimplestThing technicality is mostly a debate of semantic correctness but when pursued it becomes a philosophical fisticuff. You can start by asserting TheSimplestThing is X and find yourself arguing, moments later, that Such-And-Such is not TheSimplestThing because it isn’t Y.

In an attempt to capture the essence of TheSimplestThing, we use:
a) dictionary definitions
b) authoritative quotes
c) classic one-liners
d) Occam’s Razor

The dictionary definitions are the most controversial because they mix complexity and complicated [and in fact use them as direct synonyms] in order to define what is simple: ie. that which is not complex/complicated. In software, however, complicated and complex have very distinct meanings.

In fact, the two can never be used synonymously because their differences are big enough to create more potential chaos than a power-crazy nuclear arms dealer on crack. So, we can choose our words carefully with these two, unless we agree to use them synonymously but then to be specific about which one we are talking about. Or just keep the definitions distinct: surely that’s the simplest thing? πŸ˜‰

Personally, i maintain that TheSimplestThing is a bit of misnomer- a red-herring- a goose chase- a magic mushroom. I prefer TheLeastComplicatedThing. That way, the solution can still be intuitively *complex* [if need be becos, well, the requirement is complex] but at least, and most important, simply understood.

Further Reading:
Simple Ain’t Easy
A Field Guide To Simplicity
complex vs complicated, + xaos
No ! Your software is complicated, not complex.

Agile Relationships

The XP Coach label often gets thrown in with some other descriptive titles like facilitator, mentor, team lead, trainer in order to paint a picture about what the role entails. A big picture indeed, but not all coaches can/will fit all attributed descriptions since each is quite different, particularly mentor.

A mentorship … is a dynamic shared relationship in which values, attitudes, passions, and traditions are passed from one person to another and internalized. Its purpose is to transform lives (Berger, 1990).

If we combine the above definition and this list of attributes of a good mentor [inspired by Lewin, 1993 and Gordon, 2002]; a mentor is:
enthusiastic about the mentee’s progress
willing to help mentee whenever needed
willing to recede when credit needs to be distributed
willing to protect the reputation of the mentee through, for example, co-authorship
leading the way through support and encouragement [not through dictation]
unconditional in accepting the mentee along with his/her’s ideas

… it stands to reason that most relationships within programming, and in particular the emerging programming culture [accelerated through Agile practices like pair-programming] have an element of mentorship: coach or not. Like it or not πŸ™‚

I have benefitted more from mentors in my career than i have from learning resources. Make no mistake, these resources are invaluable but my mentors shaped my values, challenged my thinking and encouraged my passions. These determine the who i am and not just the what i can[can’t] do.

Mostly though, my menteeship has been ad-hoc [as is most mentoring, i’m assuming]. I wish it had been more explicit since the value it offers is obvious. Be that as it may for me, i do believe that in the now and in the generations to come, mentorship in software should be more explicit.

We all learn tricks from the gurus. This will never change. But where do we learn to think and how do we sharpen that axe, constructively? OpenSource/ forums/ blogs; this is part of it, but relationship is key. Afterall, computers should be about people, right? And mentorship hold some answers. Something we can all take on more explicitly as we advance, always being mentored, forever being a mentee.

Berger, S (1990). Mentor Relationships and Gifted Learners. [] In Boston, B. (1979). The mentor and the education of the gifted and talented. In J. H. Orloff (Ed.), BEYOND AWARENESS: PROVIDING FOR THE GIFTED CHILD
Gordon, J. (2002). Qualities of an Inspiring Relationship []
Lewin, R. (1993). Complexity: Life at the Edge of Choas

perspective Technology

Methodology Wars

It is interesting to see the increasingly varied responses to Agile as it waxes and wanes in popularity. From within the ranks of the new order rises a breed of zealots determined to see their ways overthrow the old. The stoics glare down at this revolution with some contempt and evidence of its untrustworthiness. The evidence itself is backed up by their reputation and that should be enough for victory. Yet the new order marches on, and in between, there’s another minority quietly getting on with fusing the gap…

I guess my view of government organisations is influenced by the incompetence of many. As grossly unjust as my opinion is, i am encouraged by many others, and most recently by: Army Simulation Program Balances Agile and Traditional Methods With Success. All this while i’ve been quietly researching on combining the two [motto: to be Agile enough to do Waterfall] and wondering just how this fusion would play out in a larger project?

Rather sweetly actually: OneSAF is a success!

This does pose a bit of a problem for the stoics and zealots though. Who gets too claim this victory? Or will they both ignore this one πŸ™‚ Or maybe we can expect a new range of books both for and against OneSAF?

Refactoring Agile: How OneSAF Could Bave Been Better.
Traditional DeadWeight: Agile Carries OneSAF.

All i can say is: “Kudos to Mr Parsons, LTC Surdu and the team on some clear thinking!”


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 ;)]


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.

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.