Life Technology

Like A Simile

We use similes and metaphors quite frequently, particularly in software. Everything is so figurative and you spend all day coming up with names for things that are “like” real world objects. Of course, that’s not counting those things which are not like anything else other than what they are in software. This is not about them. And this figurative language we carry over into customer engagements too, explaining to our dear customer why the original quote does not hold since they subsequently added the kitchen sink and “tinted windows” ๐Ÿ™‚ Not to mention explaining why that takes an extra ‘x’ weeks.
During one such session, it suddenly dawned on me halfway through the metaphor, that the client started extending the metaphor and the proceeded to re-apply it back to the software project, taking it too literally, and ended up explaining to me how software works based on the metaphor at hand. Doh! And all i was trying to do was help educate and understand…

I think IT, in general, has come under heavy pressure to talk the language of the client- and indeed, we are encouraged to keep getting better at this. Make it more accessible so that they understand… Why?

I don’t understand that thing my dentist uses to fill a tooth; nor do i care about the gadget the plumber used to seal the pipes with; and yay for the structural engineer who … well, i really don’t know what he did. But i still use and pay for their services. Did they go to great lengths to explain the intricacies of their tasks? Nope. Did it matter. Not really. I engaged them- they told me how much and how long- i paid, they did it. Moving right along.

I think the more we “passively force” non-programmers to understand what we’re doing, the more confusion we sow. Particularly when the metaphor we use is so accessible, we have no idea how their experiences, assumptions and understandings will impact on the point we’re trying to convey.

As programmers, we owe it to ourselves to forge the language (jargon) we have created, not with the purposes of creating a divide, but so that we can just get on with the job, efficiently. Without the extra fluff. Of course, that’s not to say don’t make an effort to help a client understand, if they want to understand on technical terms. Dumbing it down doesn’t really help, except maybe in polite social discussions ๐Ÿ˜‰


Software is Hard

You may have heard it before, and if you haven’t, you need to understand that. Besides all the technology and implementation caveats, competing frameworks and myriad and variety of business rules within the same vertical, there’s also the challenge of finding competent resources.

Coding is the easy part. Almost anyone can do it, given enough time with a “Learn _INSERT_LANGUAGE_ in 24Hrs” and a off-the-shelf PC. Even better, do a condensed one year course and come out the other side “qualified” and even better, command a “qualified” salary. What ludicrosity!

Now that’s not to say one year condensed courses and self-taught programmers are to be frowned upon. Some of the better programmers i have worked are self-taught. What you’re not, as a self-taught, or one year crash course graduate, is qualified. Far from it. And then even 4 years into your career, and some candidates reckon they’ve seen it all: they’re intermediate, looking for a senior post (along with the salary). Inconceivable.

Yet, this is what seems to be the status quo in South Africa right now (or at least, that is, in Cape Town). There is a massive demand for C# programmers (in particular) and the demand has outstripped the supply so greatly that the market is flowing with inexperienced skills demanding (and sometimes getting) the outrageous salary demands they’re placing. And the only reason they’re getting it, imho, is that whoever’s hiring them a) are not concerned with quality b) haven’t a clue what they’re doing or c) are really doing so well financially they can afford the risk. And maybe have a secret to mitigating that i don’t know about…

Of course the greater danger is the software that is out there. And then the pervading negative experience in bespoke software that continues because a bunch of “senior” programmers couldn’t get it right.. Go figure.

Two prominent cases recently gave the issue some visibility. The traffic registration system and the online tax filing systems. The traffic department came to a grinding halt for literally weeks because of concurrency issues on the system. The online tax filing handled well enough during the pilot, but when it was opened to the public, it hung. Badly. And we’re not talking about millions of hits per day either…

Until you’ve got about 7yrs of pure development experience (as a guideline, not a dogmatic rule) i don’t think you’re qualified enough to even contemplate leading anything. Stick around for a bit, get some more diverse experience and when you start approaching 10 years in the trenches, maybe then consider grooming yourself in preparation for more of a leadership role. Until then, you’re ultimately only bluffing yourself. Of course, it doesn’t help that the market regards a one-month MCSD as a competent programmer. It just makes it easier to sidestep your own professional integrity.

Please note, the actual number of years is a guideline and, as with everything, there is a lot more to consider than just historical “age”.

Business Life

An Agile Environment And Ergonomics

A good working environment is essential to ensure productivity in any project, even more so in an agile environment where the pace can often be quite steady, without reaching burnout. A couple of tips…

1. A spacious desk. You can’t have too much clutter or you will get distracted.
2. A gym ball instead of a chair. I’ve used one for many years now and much prefer it. It also helps avoid the programmer’s hunch.


3. Dual monitors. A luxury, i must confess, i’m still trying to get used to.

4. Stationery! No desk would be complete without much needed pens, markers and post-it notes but an arm’s stretch away.


5. Trash can. Not the virtual kind, but the real kind. Those post-it (and outdated technical specs) notes need to go somewhere, eventually.


6. And last but not least, the PC. Tucked away and out the way.


And that’s it. Oh, and one word of warning. If you ever have the urge to sneak hand-cream onto the ear piece of any of your colleagues’ phones… embrace the revenge ๐Ÿ˜€

Guys, you know who you are… outstanding job! Seriously. This is going to be a hard act to follow, but i relish the scheming ๐Ÿ˜‰

Timing Trap

It’s subtle, and easily overlooked.

Server side calls in the domain layer are setting all sorts of properties on an object before pushing it over to the database for persistence. The database receives the object, persists and returns. The domain then requests an updated snapshot from the database (which may or may not include the data recently persisted). Nothing tricky, stock standard code.

Problem creeps in when the server side code (domain) resides on a different server to the database and both servers are dealing with DateTime as a parameter for filtering on datasets. If their timestamps are not synchronized, down to the millisecond, you’re likely to get an inconsitently reproducible bug. As was the case recently…

A ‘contact’ was deactivated by setting the deactivatedTime field with a value on the domain server.
Deactivated contacts were returned by the data server based on the data server’s getdate() value.

When the two calls are sufficiently close to one another, your newly deactivated record sometimes appears in the second result set, depending on whether the two calls are within the same second according to the various timestamps on the different servers. Huh? ๐Ÿ™‚
“Esoteric”, as Eugene used to say.

And you can’t overcome the issue 100% of the time reliably. Not when you start partitioning, synchronizing, servicing and load-balancing logic within a virtual network. You can however, be aware of the problem and plan accordingly. It’s just one of those (depending on the kind of systems you’re writing) you just keep in the back of your head until it surfaces one day… ๐Ÿ™‚

Currently Learning…

So part of the whole Ubuntu move has also involved migrating my predominantly MS-based programming skillset into something *else*. As it is, i am studying part-time to complete a B.Sc Applied Mathematics, so this year will be a little slower at times on the technology front, but it proceeds, nonetheless.

So far, i’ve managed to learn a little Python and PHP. Turbogears, Django, CakePHP and Zend all occupy my headspace at the moment. The one thing they (the frameworks) have in common though is MVC, so once you have that covered, getting to grips with the semantics of each framework is a little easier.

In the process though, i’ve ended up learning a lot about my Ubuntu installations (server and desktop), managing Apache2, user rights and managing those on the system, network interfaces, MySql and Sqlite, a lot of “notepad” editing (ala nano, vi and gedit)… actually, come to think of it, i’ve learned more about *nix this year than Windows and i’ve had a whole lot more fun too ๐Ÿ˜€
Of course, i could have spent the time learning Linq, WPF, WCS, etc.. etc… but you can tell from my enthusiasm, i’ve been getting a little jaded with all the MS hype that just turns out to be the same ol’, only with more hoops. To be fair though, i did enjoy some of the .NET porting to Mono.
And that’s been the difference: the fun factor. Learning is fun. When it’s not fun, it’s not learning. It’s cramping.

What to do… what to do…?

I just couldn’t resist ๐Ÿ˜€ Had to log into Windows today and on startup was presented with this dialog:


What do you do?

Fractions and Foating-Points

Floating-point arithmetic on a computer is hazardous, at best. This post is not a detail description of the problem. Varied descriptions of the problem already abound, like this one, for example. There’s also documented pain out there to understand that it’s not just your computer ๐Ÿ™‚ No, this post is just one way of getting around the problem in a particular context.

The environment: JavaScript. The problem: convert decimals to fractions and fractions to decimals. Getting a decimal is straightforward:

function fractiontodecimal( wholenumber, numerator, denominator ) {
wholenumber = parseFloat(wholenumber);
numerator = parseFloat(numerator);
denominator = parseFloat(denominator);
return ( ( ( wholenumber * denominator ) + numerator) / denominator );

Obtaining a fraction was slightly more insane since in JavaScript
23.8 * 10 = 238
23.88 * 10 = 238.79999999999998

Not exactly what you need to work with. As you can imagine, inside a loop of sorts, and if the number becomes very small and you divide by it, you start getting bigger errors. Anyways, that’s a digression in itself. What i needed was a reliable way to multiple by a float by an integer, 10, and get a predictable response. In other words, i just needed to keep shifting the decimal point. Most immediate response might be: string manipulation. Isn’t that what JavaScript is for? :p

Another way was using e-notation. 23.88 being represented as 23.88e0. Multiply by 10: 23.88e1, and so on. The good news is you still get to do a little string manipulation, but not nearly as hectic as finding and moving a “.”

The particularly heavy looking string manipulation looking like:

newDecimal = mantissa + “e” + exponent;
That wasn’t so hard, now was it? ๐Ÿ˜€

Browse through the code for decimal.htm (HTLM page with JavaScript)


Not gonna lie- it wasn’t altogether _that_ intuitive to begin with. Appenders, logging levels, loggers and a whole bunch of different configuration going on: it wasn’t just working. But, i thought to myself: many others are happy with it so it must be worth the initial pain. Of course, in a world of instant gratification and high-speed demands, how long exactly do you sit with a problem?

If it’s a maths problem, like something involving integrals, sometimes you can do nothing but sit with it. No amount of Google is ever gonna give you the answer. And if you think it can, i’ll happily take on the challenge ๐Ÿ™‚ But this is code…

CodeBetter, CodeProject, Koders and even log4Net itself have plenty of sample code and tutorials designed to get you off the ground. And they all have their strong points so if you thinking about log4net, take some time upfront just to read how different people go about explaining various setups and configurations. You’re bound to find one you like. So back to this particular log4net experience…

What i wanted is to have an open console running which recorded anything i wanted while my application was executing. i love consoles ‘cos of their simplicity, power, flexibility and in-obtrusiveness. in the right place, at the right time, they definitely rock. So that’s the mission.

There’s this article which gave me a great jump start in the right direction. I made a few modifications (i am programmer) and as a result… well, this picture is worth a paragraph or two:

log4net console
More than anything, this is testimony that log4net really does work despite some of the comments and posts (and initial pain) and once you’ve got it down, you can add massive geek-value to your project. You also just might have fun, but keep that to yourself ๐Ÿ˜‰

Go on… have a little fun

Worse Than Failure are hosting a little contest, which perchance happened to stumble upon. it is just for fun [eegads! don’t let anyone know you’re actually having fun programming] so my entry is up… who knows, maybe it’s a good enough attempt at winning that high quality JPEG! ๐Ÿ˜€


the “O” word popped up today and i can recall reacting rather negatively to the concept. having recognised my emotional response :), i’m trying to gather my thoughts so i can examine the role of overtime in a production environment with reasonable judgement. and in scanning through many articles, my reaction is more accurately against planned overtime, than overtime in general.

Indeed, when a project starts planning for overtime consciously, there are bigger issues that will lead to some demise, sooner or later. Something’s always gotta give. An interesting extension to this concept is subconsciously, or even unconsciously, planned overtime.

Subconscious planning is probably based on a mix of the following [and not limited to this list]:

  • good intentions
  • a desire to please
  • ego and pride
  • manipulative characters
  • messiah-complex
  • politics

You’re subconsciously factoring in a hero-effort *somewhere* along the lines, and you know it. Maybe you’re just not stopping for long enough to be upfront about it? You have theร‚ย experience, you knowร‚ย about chaos, and you really should be more accurate by now.ร‚ย But you override sound reason. And that’s where unconsciously planned overtime differs. You didn’t know at all that what you were planning would involve a super hero push to try and rectify the quickly deteriorating project. Basically, inexperience in the domain you’re managing.

And i guess that’s how software got it’s reputation for being so overtime-driven. Unconscious planning in the early days was due to not knowing just how hard software [your project] really can be. But we’ve learned that and moved on from there. We have the statistics and collective experiences of many to testify: overtime kills. So, today, if you’re putting in overtime, you got to ask: what kind of planned overtime are you dealing with?

Of course, there’s always gonna be unplanned overtime. Power failures, natural disasters, trauma, sudden massive economic instability and similar left-field events are not usually factored into _any_ project. But they also don’t occur every day, or every week, even every month. These are rare occassions. Not your run-of-the-mill experiences that justify a demand for working overtime.

So where does overtime fit in, apart from natural disasters? For me, it would be when the team decides they want to do something _extra special_. Something out of the ordinary to take advantage of a window of opportunity or close a critical gap. And if your software is always full of critical gaps… ๐Ÿ™‚ need i say more? It’s that extra burst of special energy that contributes significant value, and therefore requires that extra special commitment.