Setting Standards

Guy recently referred me to an article on how user’s read the web. It’s implications were poignant when mixed with the motive of acceptance and market share.

We know the most efficient way to consume online information is through the technical process known as “scanning”. From emails to advertising, knowledge to news, online users inundated with information have established a coping mechanism of scanning. As presenters of online education material, do we acquiesce to the the masses and achieve acceptance and market share by presenting radically shortened content? Or do we draw the line and encourage proper reading habits through presenting albeit verbose; accepted educational tautology?

A different discussion, but one closer to this thing called software development; how much of what we do, as a software community at large, results in encouraging bad behaviour?

When you sing, you begin with doh-ray-me, when you code you begin with “what say ye?”. Indeed, what sayest the project investors? Beginning with the processes we choose to manage and define our project, how much of what we do becomes an AntiPattern? Further, do we aspire to eradicate that strangling weed in future projects. This is not a process-related condition, it’s a human behaviour condition and so it affects the traditional plan-driven, the agile and the anything in between processes.

Language support too has its fair share of nasty accommodations. I recently ended on the guilty side of calling a pure virtual function from the constructor. Oops. Now, in C++, you’re likely to get a nasty dialog box or even better: a compiler warning. With C# and Java though, although not a recommended design [and sometimes classified as unpredictable, depending on whose documentation/interpretation/blog you’re reading], the memory model does allow you to get away with it- and what’s worse: all your tests will pass! 🙂

Lets look at browser differences and XML data islands. They make life very easy [for simple things]. Building that into a dynamic-content interactive online small-medium enterprise application has great potential for building another BLOB. Granted, anything can become a BLOB if you you don’t manage it properly. In this context, as handy as they are, are not the norm for this project which implies extra process burden in terms of managing it’s lifecycle if included. So without even going into CSS differences, browser standards can breed their own demons. And considering CSS support, IE lets you get away with a lot, but at what cost to your career as a designer?

Database engines suffer the same potential for disaster. There’s a standard which is not always designed for rapid development and then there’s the exception to the standard [eg. self-incrementing fields] which does make development a little easier. Again, at what cost?

Of course, the counter-argument is concept focused on pioneering; trend setting and evolutionary. So you can, as with everything, form an opinion first and then pick your arguments to justify your position. Be that as it may, CheeseOriented debate is quite tiresome.

In your arena you need to decide what’s ultimately detrimental and control that within your area of responsibility. In a largely collaborative software community the decision makers that defend or propose standards determine the greater good. They engineer the breeding ground for the programming quality of the future. No wonder these standards issues are so hotly contested. Regardless of how much is motivated by purity of intent and how much by market share opportunity, we will ultimately be forced to work with the standard of quality we didn’t fight for.

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…

Language Appeal

What makes one language more popular than another? Why would a language like ‘C’ be so visible and popular amidst today’s advancing 4th generation languages? Methinks the same reasons why English is such a popular communication language today…

Tear and tear. Look the same but quite different. Tear has more in common, phonetically, with bare while the other is closely related to beer. Hair and hare. Red and read, the past tense of read. Break and its past tense broke, yet brake and braked, as applied to a motor vehicle which came to a sudden stop.

So we have a range of words that break all the rules and it has been said, more than once, that there are more exceptions to the rule than not in the English language. And let’s not even consider the variances in English, which we all assent to being, by and large, English. American English, British English, South African English and then Spanglish and the like.

Yet with all it’s complexities, it’s gaining popularity around the world. One reason [out of many] why it continues to be so popular is because you can do so much with it and still be understood.

I sed tht i’d b l8. w8 4 me. c u sn!

There are times when de-intellectualising a conversation can be welcomed.

In most other languages you can’t even do half of what i’ve just achieved above. Yet, most anyone reading would understand what’s been typed. And for the non-legalistic in us, that’s enuff. And more. It’s a sign that we can explore boundaries of that one human domain of ours which is so sacred and yet so vulgar: communication.

So if a programming language, regardless of its complexities, gives us the freedom to create within itself, it will prove to be popular. Classes, templates [aka. generics], polymorphism, reflection; facilitating the art of creating in order to communicate is of paramount signifigance in terms of a language’s popularity. But it depends on “what” you want to create.

Adressing memory, pointers, embedding assembly; different kinds of creational facilities but again, oriented towards enabling your creative side in effecting communication.

C#, C, C++, Java, php, perl, vb, sql, python, shell, delphi, ruby, fortran, smalltalk, erlang, cobol, tcl… they all remain popular, within their own right, contrary to any “silver bullet” promotions in any one particular language because they continue to provide the programmers with their creativity fix as part of getting the job done. When the language becomes so inhibiting that there is one and only one way to do something, it shall quickly die a welcome death.

“What do you mean i can only ever have one type of Class: sealed?!” 😮

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


Rules are meant to be broken, or so the popular expression goes. There’s something about that phrase which strikes a chord of assent within ourselves. There’s also another chord which repels strongly and begs for rules to be followed. As a result, we swing between judgements as to wether or not a rule should be followed or broken depending on circumstance. We confuse this swing with perspective because we have failed to implement a principle concerning rules. And we fail to implement principles because we fail to understand the intent of the rules.

From software processes to religion, politics to social behaviour, there are rules. Divined or ordered, these rules become established within a context and serve as an education for acceptable behaviour. From the start of implementation, two extreme camps set up early to hold the rules in dynamic tension. The legalists and the liberalists. Those who obey, to the letter, and those who don’t.

In the those who don’t obey category, some break rules because there’s another rule which justifies their position. Others break the rules through ignorance and others through a conscious anti-social drive. In the those who do obey rules category, there are also interesting differences.

Some will cross their t’s and dot their i’s so carefully, they end up missing the purpose of the rule itself. The rule itself becomes the end. The reason for the rule’s existence forgotten and not as important as actually keeping the rule. Others will keep the rules steadfastly in the hope that the end will be achieved through the means. The motives for any one position [and this brief list is by no means assuming it’s complete] are numerable and can even be the same motive for different positions. So what are the essentials of the rule?

Before the rule, there was a condition. In order to [usually] discourage the growth of that condition, a rule is established to improve that condition. When that rule starts to be applied outside of that condition, or is contrasted with another rule, more rules are entrenched to further clarify an increasingly complex set of conditions.

So, if we get back to the essence and reason for the rule in the first place, a decision to “break” or follow the rule becomes simpler. It can also take more courage [either way] since it could fly in the face of a traditional interpretation; however wrong that interpretation may be. But challenging rules and breaking them are 2 very different actions that may actually manifest with the same result.

Now that the essence of the rule is defined, a decision needs to be made regarding its worthiness in keeping. But that’s a moral decision based on belief systems and is impacted by who exactly the rule-giver is; and that’s another discussion…


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…

It Depends

Which language is better: Java, C++, C# or VB.Net? Well, it depends.
Which is better: MS-SQL or Oracle? Again, it depends.
Which is the best implementation for a singleton? Mmm… let me think. Well… it depends. This ever popular and increasingly quoted phrase, “it depends” has nestled itself into our reactive vocabularly because well, “it depends” on a lot of factors.

From platforms to databases, frameworks to languages, compilers to GUIs, the variables in this game called software have multiplied radically. To think one solution can satisfy across all domains is declaring that you found the Holy Grail; the Silver Bullet; the Rabbit’s Foot- call it what you may. The problem with the Holy Grail is that no one [alive] has ever really seen it, so when you do present it, how do you argue beyond doubt that it is The Holy Grail? Hence you should not be surprised by the stares when you declare in a moment of technical triumph, rising from your cubicle in wondrous glee: “VB Rulz the World!” Well, yes and no. It depends…

Debates for and against, and within Agile come from different perspectives. Similarily, for and against, and within C++, the debatees hold different assumptions. An optimized implementation for one team, is not guaranteed to be the best solution for another. Team 2 might not even understand the code and hence not be capable of maintaining it. Or instead of optimization, throw a Gig or 2 of RAM, or a second processor at it [cheap at the price compared to a programmer] and watch how that routine suddenly improves in performance.
“That won’t always work, you know!” Yes, i know, it depends on the problem and the optimization.

And this is precisely the point, it does depend on a lot of variables. Even the very statement “it depends” is not applicable in every situation, because well… it depends on the circumstances 🙂

Communication Instinct

Many of the challenges facing software processes today are not new. From the social to the technical, these challenges are also not unique to the software world. Dissension amongst the ranks and disillusionment with management are common social problems within any company; and more, within any group of people who co-habit for a length of time. What and how to act [implement] are also sources of diverse technical opinion and impassioned debate between those in the know. Nonetheless, as common [and age-old] as our predicament is, it has it’s own distinct flavour spiced up through consistently bad communication.

Statistics aside, our collective experience testifies that business [“them”] and development [“us”] fail to understand each other as clearly as we would like. Starting with the requirements gathering phase, the problem definition is already corrupted. There is enough satire available to substantiate this undercurrent of truth [even without Dilbert] that there is something horribly wrong right from the beginning.

Agile, waterfall, functional specifications, UML; all these and others try desperately to accommodate vague definitions or legalistically bind definitions on opposite sides of the spectrum. Even the middle path fails sometimes. As hard as some try, they will fail with spectacular disillusion, regardless of how absolutely brilliant the idea is. Execution is key.

To execute, we need “a” plan. Once we have “a” plan, it needs to be communicated in a way that is understood with clarity by each member involved such that each is of the same mind and vision. And in successful execution, this communication tends toward the less verbose and more instinctive over time. Team members learn to read each other.

Why do newly formed sport teams get better with age [assuming players remain mostly the same]? Why does their game break down when the team is shuffled? Why is it so hard for new team players to break into a team? Why do they even need to break into a team? As a team gets better, their communication is reduced to a twinkle in the eye; a mono-syllabic reference to a previously successful play; the slightest change in posture. If they had to communicate from first principles each time, their progress would be slow. New team members need to absorb these nuances and shared histories in order to fit into and contribute to successful play.

The same can be said of a software development team [which, by the way includes both the “them” and the “us”- a one team mentality, but that’s another discussion altogether]. The team needs to progress to a point where business analysts only need say one thing in a particular way and immediately the technical team understands the play. Yes, this may take some time and work. More over, it takes courage and patience.

Changing teams all the time doesn’t help things much but maybe the teams change because there is no perceived progress. Another chicken/egg scenario [btw, the chicken came first]. That aside, a committed and successful team will endeavour to refine their communication and work hard at understanding each other.

Imagine business investment looking the technical team squarely in the eye during a round of requirements gathering…
BI: “Status Updates”
TT: “Done”
And the expectations of BI are exceeded upon delivery. Fantasy? For sure, but that doesn’t mean we can’t aim to achieve a measure of that.

Agile, waterfall, functional specifications, UML, et al, are all tools to aid communication, not replace it. And as with any tool, the job is easy if you use the right tool at the right time for the right job. They should not be ends within themselves but a means to achieve a greater understanding of each other. And in developing these communication tools, progressing in them for the sake of expertness without a greater awareness of their communicative double edge, restrains the more powerful instinctive and natural communication. It is this kind of communuication, when manifested, which is able to break all barriers of understanding and promote real value.