The Carpet

there are times in life when we see those we love hurting themselves. and true, it is just what we “think”. but we become convinced in our thinking that the course of action that they are pursuing is not a fruitful one. on the contrary, by all accounts it will be quite a painful end. and while we “see” that inevitability, we hope in the place where hope is guarded fiercely, that we are wrong in what we see. nonetheless, we stand as witnesses to their deeds, and more; we are with a better view since we are not blinded by influencing motivations. but what do we “do” in a situation like this?

there is a reasoning which hides behind the barrier described as “acceptance” and “love”. this reasoning also fights against the labels of “judgement” and “intolerance”. yet these are just useful labels wielded around carelessly with scant regard to the reality of what they represent. it is also in my experience, being a believer in Jesus, the Risen Messiah, the Redeemer, and solely on this basis alone, that the actions of many a christian are more readily labelled as “judgement” and “intolerance” rather than “love” and “acceptance”.

if a drug addict is needling him/herself to the point of destruction, do we just stand by and proclaim that we love and accept that person, the way they are, with all their weaknesses, and support them 100%… and not say against what they are doing? and alcoholics. there is no shortage of people ruining their lives and the lives of their families by their drinking habits. do we just accept them because we love them and say nothing against what they’re doing? and those getting divorced, splitting up families, having extra-marital affairs…. do we just say nothing against those things? we must just accept those things as casualties of a hard and difficult life? and i’m not referring to these concepts from a distance either, i’m engaging on a level where someone you love is struggling against these issues. it’s easy to philosophize from a social-psycho textbook and opion-based theory. that has it’s time and place, but what do we actually do?

me, i speak out against it. i disapprove. i encourage to not pursue that course of destruction. but that’s being judgemental. if i stay quiet and sweep it under the carpet, maybe make one or two passing comments which reflect my uneasiness about the situation, then i am showing my love and support and acceptance of the person. and when did that become so twisted?

indeed, many an evil flourishes in silence. and under that carpet where we just sweep so many things away, we choose not to fight for those who do struggle. we choose to support their path to self-destruction because somehow that’s almost easier than actually making a commitment to love them lest you take a stand and get kicked in the teeth for doing so. or maybe we just don’t really believe that what is being done is all that bad anyway, so what’s all the fuss?


Night Surfing

noooo, not the web kind of surfing… the Aloha-Hawaii-Dude!-style of surfing… at night!

it was a super day, saturday. started off with a wedding in the morning [wooohooo, Mr & Mrs Couvaras! 😀 ] and then settled into an evening braai at A+L. Great dinner, fantastic pudding followed off with a warm cuppa coffee. Just when you might have thought it was time to settle into a game of cranium, or slow down into some more good conversation- the *almost* full moon came out from behind the clouds!

well, there we were, 4 of us, scrambling for surfboards and wetsuits, hopping down to the beach at 10pm! a very odd sight indeed. splash! into the water and paddling out to … erm… well, just paddling out 🙂

the water was FROZEN!, the moon had snuck behind the clouds once more but luckily the waves were forgiving. once or twice you got to sit out backline *all by yourself* and more than once i saw shadows darting beneath my board! :S imagination is a tricky thing!

surfing the waves was awesome though- only the moonlight to guide you, not knowing if the section was going to break or not, not sure just how much the wave is sucking up- all you can do is just feel your way… awesome!

we surfed for about half an hour- the onshore started messing with us- before heading back home… an even odder sight since this time we’re all wet hehehe

highly recommended, but at your own risk!

i won’t hesistate to add that before we headed in, we prayed and during, we prayed, and after, we prayed. God is good and for that one sweet night, He protected us while we went about our crazy surf, just fully relying on Him for the rest!

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!”

Life perspective

Mother City Riots

Rated as one of the places to visit, Cape Town has just about everything to offer the resident and tourist alike. And all kinds of residents and tourists are catered for; from the dodgy back-alley fix to the deserted beach moonlight stroll, Cape Town offers it all. But that in itself does not make the Mother City special. Just about every international destination has its fair share of glamour and sham. What does make Cape Town beautiful, is “tha mountehn”.

Aaahhh, tha mountehn. No doubt about it, there’s something about that piece of rock which takes the edge off of life and slows the city down to village trot. From sandboarding to surfing, sunsets to riots- Cape Town has it all.

Wait a minute?! Riots?! Yes. Riots. Now, for those who live in Cape Town or have been following its news, the current “Security Strike” has been going on for close to 8 weeks now. The fruit of the last 8 weeks of discussions has been summarised as a “deadlock”. In the meantime, those who choose not to strike get murdered or beaten. Further, while security is not available, gangsters and thugs take advantage of the situation to help themselves. Those who have the ability to put an end to the strike claim helplessness and all the while, they fuel the frustrations and anger which boil and burns until one day…..

No, this is NOT a picture taken during an apartheid South Africa. This is 16 May 2006, 12 years into building a democratic rainbow nation. On one hand:

“Our right to protest is an essential right. Our right to strike is guarenteed in the constitution.”

But does that include the right to murder, set busses on fire, vandalize the city and loot? But make no mistake, those on strike have a legitimate concern which is not being addressed. Their wages have not increased in 12 years?! Although not condoned, is this not just a case of “going postal” on a wide scale? How many of us have felt the frustration of not being heard by INSERT CORPORATION HERE and have wanted to scream, shout and throw a hissy- maybe even beat someone up. Some actually do, but they pay the price for their anti-social behaviour.

However the mayhem and chaos closes, better it stops soon. Unlikely though when the negotiations are conducted in the spirit of power and domination; no real sacrifices and flowering with taunts and poisoned with emotive appeal. An interesting piece of fuel in this fire is demonstrated by some of the placards carried by strikers: “US and EU are anti-poor” and “Down with imperialism”. But that’s another discussion…

Aaahhh, tha mountehn!

Some more riot photos below that were circulating on email. Warning! These are, IMHO, controversial photos and probably best not viewed if you’re a little queasy or are very sensitive to harsh images. Also, i don’t know the context of these photos so don’t even pretend to judge the photos and the incidents or me by these images.
I just find them fascinating from a politically-photographic perspective ‘cos they carry so much power to potentially skew the truth… there are more incriminating photos which i’ve decided to leave out ‘cos they’re just too hectic for this blog…

Business perspective

Continuing Education Gaps

Reading through one of Karl Seguin’s blogs on ASP.NET isn’t always the right tool it convinced me more that there is a gap in software education. Not in formal education, but in continuing education.

Computer-science and programming curriculums at tertiary institutions have remained fairly static over the years inline with accommodating their primary objective: concepts. They will use a set of technologies in order to convey those concepts but not often do they specialise in that technology [at least early on in the program] purely for the sake of that technology. That’s where continuing education takes over. You won’t go to university to learn Apache, but you will learn web server concepts. Outside of university, it’s your ability to join the dots between web server and Apache and apply that knowledge [wisdom] that determines your worth.

Formal education has the advantage that concepts don’t change as rapidly as the tools and technologies. It’s continuing education that sit with the task of trying to keep up by providing “expert” education on new technologies. And since this is an ever-changing and time-consuming task, the foundation established by formal education is not taken advantage of. It’s not an objective. That is to say, the language of function [the what] disappears from the curriculum and the course becomes a powerpoint presentation dripping with the language of form [the how].

Considering that business processes and requirements have increased in complexity, programmers are required to know [minimally] “how” to solve these issues. The available toolsets have managed to meet those demands [and some] and assist the solutions, but there is a lot more going on that you need to be aware of, albeit even vaguely. And when you engage in advanced tools to faciliate advanced business needs, the demand that you know what you’re doing and not just how to do it, increases. From managing a web farm to architecting an e-commerce site, knowing how to do it is half the task. When you know what you’re doing, you’re better equipped to handle the esoteric stuff Mr.Murphy is well versed in at throwing your way.

How to distinguish postbacks in ASP.Net seems trivial. Look up the sample code and documentation and without further ado, IsPostback will solve all your problems. But what is a postback? Why do i even need to distinguish it? [you think i’m kidding? :)] What data is riding on a postback? What methods are invoked during a postback? What happens when i have dynamic controls? Knowing a little about the what behind the scenes goes a long way to solving a “but it just doesn’t want to work” scenario. It will also eliminate the many “WT..?!’s” you might come across when reviewing code before releases.

The problem and the solution is shared between both continuing education providers and learners. Learners need to realise that just because InstitutionX gave you a certificate that says you can do the job, it doesn’t mean you can. When you learn “how” to assign directory permissions, or “how” to nest repeaters, keep in mind “what” you are actually doing. To understand the impact of “what” requires you to invest further in your own education. It’ll only make you stronger. Educators don’t have the time/resources available to point out what may seem to be obvious.

Think critically. Remember what you have learned or at least know where to find it when you need it. Be conscious of every line of code you write. Know exactly what you are doing. Write tests! And if you don’t know why it’s breaking, it’s because you probably don’t understand why it was working in the first place… :p


Dynamically Nested Controls ASP.Net

The solution seemed simple enough and what’s more, it should have been a straightforward implementation. Should have been. After one or two false starts, we settled into an approach until we hit the ubiquitous viewstate issues. It’s a silly problem to be having really, given that every server control automatically manages its own state. True, there are constraints and conditions, nonetheless, the theories are not rocket science.

The page dynamically loads a “layout” usercontrol, depending on user context. This layout dynamically nests a “view” usercontrol, again depending on module within the application. This view then dynamically loads one of n “function” usercontrols on a postback. And therein lies the rub. This function itself posts back data from it’s children, one of which is typically a repeater or other custom usercontrols. Further, each repeater item may contain N server controls. After the postback, the page loads and all the viewstate across all the dynamically nested controls and their children load perfectly, viewstate intact. Simple.

The concepts: each server control maintains its own viewstate [good encapsulation]. The viewstate is heirarchically defined and processed at specific points [good definition]. This is a recursive situation, so if it works for one layer, it must work for N layers. The problems: confusing my requirements with another blog’s requirements, vague newsgroups and technical expressions, sometimes ambiguous documentation and a lot of CheeseFactor :).

After a fresh restart, simplifying the problem domain and applying recursive heuristics the solution is indeed simple. And as simple as they are, i often wonder why/how/where the connection points get missed? Methinks the language of function within the education process is not as sufficient as it could be, but that’s another discussion. So, in summary:

• Always load your dynamic controls, even on the postback. The (!IsPostBack) is not an decision you can use for deciding to load controls dynamically. Use that for binding data.
• Page dynamically loads control inside OnInit(). By the time you hit Page_Load, it’s too late for anything viewstate related, particularly when we’re looking at nested, nested controls.
• Give your dynamically created controls a unique ID. Better for debugging so instead of trying to figure out the tree through reading _ctl1, _ctl2, etc.. The tree now reads as Main, Layout, View, Function, etc… Write code for programmers, not for computers.
• Immediately add the dynamic control to the tree before setting any properties on it.
• With dynamically nested controls, follow similar principles as for page. Don’t dynamically load a nested control inside ControlLoad. Too late. CreateChildControls works much better.

Following these guidelines, your nested, nested controls maintain viewstate perfectly with no additional plumbing. Including all repeater items containing additional server controls and other custom usercontrols.

Tools, Ideas and References:
Concrete Mathematics, A Foundation For Computer Science, Graham, Knuth & Patashnik
Authoring Custom Controls
Dynamic Web Controls, Postbacks, and View State By Scott Mitchell

perspective Technology

The Right Tool

It’s a theme which comes up quite regularly: “the right tool for the right job”. From DIY to software, this mantra manifested literally saves you money. Let alone a bundle of emotional energy which gets exhausted trying to fit round blocks into square holes. I can use a knife as a screwdriver, my cellphone as a delicate hammer and chewing gum as glue. As much as they work, they are not the right tools for the right job.

In software, we tend to think of tools as: inter-alia, compilers, languages, debuggers, IDE’s, SDK’s and drivers. Very rarely do we regard our processes, resources and skills as tools. We define these instead as attributes of a project, team or individual. But attributes are abstract things such as value, determination and enjoyment. Of course, we don’t want to offend any person by referring to them as a tool. But let’s rise above ourselves for a moment here, and ignore the connotations of “tool”. In doing so, we can take advantage of the definition to pursue success with greater enojyment.

The challenge: need to respond to aggressive shifts in the market and stay ahead of competition by releasing features rapidly. The tool: Agile.

The challenge: need to carefully plan out the next n months of development in a mature vertical market. The tool: Waterfall.

The challenge: need to research algorithms and implementations of those algorithms on different platforms. The tool: established computer scientists.

The challenge: need to mentor a team of young programmers within a business application product. The tool: pair-programming.

Instead of dogmatically insisting that the “attributes” of your project: Processes, Resources and SkillSet determine the course of your project, let the real attributes: success, enjoyment and value be a product of your project- but manage those just as pro-actively as any other aspect of the project. And while you course through your project, employ the right tools for the right job at the right time.

And just because a hammer worked really well driving that nail into the wall, it doesn’t mean it’ll do an equally fantastic job at attaching the mirror to the wall.

The irony for me though, is that we all instinctively know this and by some subconscious decision making process, we apply this principle quite well to a point. It’s when we don’t apply this principle though that we end up in a: “Houston, we have a problem”.

I think the art of getting this right, is like anything else: be conscious of what you do and decidely know what makes you successful. Like your code, when it unexpectedly stops working, it’s probably because you are not really sure why it was working to begin with…

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.

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.

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.