Month: May 2006

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.

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

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…

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 🙂

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.