Software Updates

It’s perhaps appropriate that i should update my blog with a post on Software Updates. Been quite busy with some exciting delivery my side along with getting a new machine mid-iteration, which is a decent distraction: T60 2.4 Duo. VERY Nice machine and overall impressed with, well, just about everything- particularly ThinkVantage. But in getting my machine production-ready, the sheer volume of updates that i had to do was *staggering* [slightly exaggerated] which got me thinking about my Gran…

Approaching 80, she’s actually about 60. She emails and uploads photos from her digi cam and keeps track of her budget using Excel. Not bad for a soon-to-be octogenarian. But how often does she update her PC?

First, there’s the OS updates- in this case: Windows Update. Then there’s the driver updates for anything particular on your machine. Then there’s manufacturer-specific system management updates and that’s before you get to your “third-party” application software updates like anti-virus, for example. And these are not small updates either.

Windows Updates: about 21 in total [many MB] and the machine came preloaded XPSP2.
Driver updates: ATI as an example: 47MB! Thats’ not including updated drivers for fingerprint readers, wireless drivers and yadah yadah.
System Management Software Updates: Yes, ThinkVantage itself needs to be updated before you can use it to check for updates ๐Ÿ™‚
AntiVirus updates: using AVG and that totalled about 15MB from my current installation. Could have used preloaded Symantec but the updates are just as heavy.

Granted, not all these updates are critical- but how grokkable is determining severity levels based on the information presented:

“No, ma’am the ATI update is not critical, but we do recommend it” – or-
“that update for XP 64-bit is optional, so don’t worry about it.” Which means what [to my Gran]?

With all these updates needing to take place, and getting back to my Gran… What happens if i DON’T run these updates regularly? And another thing: WHY are there so many updates?

Is the software just poor quality?
Are all these companies finally adopting Agile and releasing incremental “enhancements” as opposed to fixes? ๐Ÿ™‚
IS QA just getting better at what they do and finding more and more problems?
Are systems become so complex that inter-operability and coding for it is laying a foundation for latent problems?
Is software been pushed out the door because the market has become so aggressive that an incremental release strategy helps keep the company competitive?
All of the above?

Too many questions for a Saturday morning, but i wonder just how many new PC/laptop owners install updates knowingly? And if they don’t know they’re actually updating [preconfigured under the guise of “user-friendliness”] if they notice their bandwidth getting hogged every so often?

…there’s a surgeon doing a remote heart transplant operation and s/he accidently removes the kidney as well because the system software was not configured to update automatically… ๐Ÿ™‚

I think we still got quite a way to go before we can comfortably integrate technology easily into our lives…

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.

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?!” ๐Ÿ˜ฎ

Rules

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…

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.

Quick And Dirty

Programmers write a lot of code. Some of it good, some bad, the rest just plain fugly. There’s code to provide functionality, code to prove a point, code to research a bug, code for fun; well, code for every occassion. So let’s examine the production occassion.

We’re employed to implement a feature and there’s a lot of code that needs to be written. But before we settle into implementation, we need to locate where it will belong. Like my cats kneading their sleeping spot, we refactor our bed of code to setup our work area. Then we settle into the business of production code. Red green refactor commit repeat.

Now when implementing “serious” code, we sometimes forget that QuickAndDirty code is just another tool in our box in order to get the job done. Faced with a lengthy workflow, there’s nothing wrong with plugging in un-cohesive, tightly coupled structs/procedures [ =:-o ] to get your thoughts down and documented. Of course, as with any tool, you need to use it correctly in order to get happy mileage out of it.

But just because you’re doing serious production code [and pair programming] don’t be too self conscious about the code you write. Be bold and get dirty. Write quick code to make it compile and flow. Just as red green refactor mantra is applied to tests; the same can be applied to production code.

The major advantage is that you don’t have to keep a hundred threads tied up in your head all at once while you journey through a workflow or a concept. Along each step of the way, there will be discoveries and unanswered questions about what [not] to do [particularly for UI based work]. These distractions can add up quickly and before you know it, you’re coding down a path that when you finish, it takes a while before you find that trail again.

Oh and by the way, don’t leave your tools lying around for others to trip on…


note: production code here is used to distinguish between purely test and deployed code, although i regard test code as production code in my environment.

Embracing Conflict

We all think differently, and this is a good thing. And there’s definitely value for particular paradigms at different points in software lifecycle. When we use the wrong paradigm at the wrong time, we end up in situations less desirable.

Researching the anti-patterns related to abstracting too early, it becomes obvious that implementing an abstraction ahead of its time results in bad design. Apart from the complexities and maintenance, there are hidden dangers about the assumptions subclasses make when they override methods, particularly over time and changing development teams. Couple these and you can end up with a time bomb.

This [abstracting too early] particular concept has resulted in endless [moot?] discussions within Agile teams debating inter-alia, upfront design, YAGNI and simplest thing. These “discussions” have divisive power and can hinder progress if the fruit of the discussions is not managed appropriately.

Yet, there are definite advantages to thinking this way. Thinking in the abstract and seeing a bigger and more vague, yet determined way, can be useful in spotting potential problems down the line. Thinking in the abstract and visualising complex inheritance heirarchies and patterns upfront [so complicated its bound to impress the client :)] adds value to the discussions and directions by adding scope to thought.

It becomes a problem when one argument insists, dogmatically, that the ObviousImplementation is the only road to take and the psychic team insist, equally vehemently, that it is the only road to take. And don’t think that a public opinion poll is going to substitute for real thought.

Regardless of the judgements ultimately placed on any pattern, or anti-pattern, methodology or approach, a successful team can work productively within the apparent chaos and all it’s contradictions. Deciding when to use which paradigm is a critical decision. Deciding to dogmatically ban one undesirable paradigm, largely because it surfaces at the wrong time, is a shortcut to weaknening your team and disempowering your colleagues.

At each end of the contradiction is a powerful force that needs to be maintained in tension with it’s opposite. By harnessing this tension you can maintain a steady and powerful course, but be willing and prepared to use the opposing powers when the balance shifts unexpectedly. The degrees to which you need to harness are determined by the degree of imbalance. And if you don’t proactively manage these forces against one another, they will ultimately clash and spiral into destruction.

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.