Wille Faler’s Buzzword Bingo

(YouTube video)

..this is the sort of stuff you get when you have marketing and “enterprise architects” sit down and compare powerpoint-slides..

Unit-testing code tends to be something people either don’t do at all (or do hastily and begrudgingly), or do judiciously. In my experience, there is rarely any moderation when it comes to unit-tests, and the reason for it can be easily explained by the fact that people tend to either get it, or not. Those who don’t get it think its a waste of time, those who do get it love doing it and have realized the long term benefits of good test coverage.
Looking at the evolution of me “getting” it, I can easily recite the steps I went through:

• “Why would I want to do that?” (that was literally my first reaction back in 2002 when Markus started to try and persuade me).
• “It’s a nice concept in theory, but how do I do that?”
• “Hm, this is kinda useful, I wonder how I could do more of this?”
•  ”I’m getting the hang of this, seeing 100 tests pass is cool!”
• “What the hell was I thinking before?! I should never have done anything else”

This pretty much mirrors the development of my attitude to unit-testing over the last 5 years or so, and I think it probably mirrors the attitudes of many others. Unfortunately though, very few people are in “stage 3″, being on the fence, most people are either in stages 1-2, or 4-5, and getting from 2 to 3 is probably the single biggest shift in attitude that is needed.

Why is it so hard? It probably has to do with human nature: A lot of the time our habits overwhelm our rationality, we may very well buy into something on a rational level, but the concept is not yet integrated deep into our habits and personality. There is a definite step between logically acknowledging something, and subconsciously believing and knowing the same thing. That is often the missing factor.

Over the years I have seen a lot of code written by a lot of people, some of it good, some of it bad (mostly bad, because lets face it, haste, lack of motivation and outright mediocrity is pervasive in IT). This has made me realize that there are a few very clear hallmarks of code that is of good quality, to me the biggest ones are the following:

• Easily testable (in fact, I’d say code that doesn’t come with unit-tests is bad most of the time, and yes, that includes most of my own code ca <2004)
• The code doesn’t try too hard to second guess itself by being “future proofed” and generic, yet bends easily to new requirements without breaking too many existing interfaces
• Once a newbie gets the general concepts of the code, it is easy for him to get stuck in and start creating new functionality without duplicating old
• It is easy to refactor the code, even dramatically so without breaking anything (because you rarely get it right the first time)
• Goes without saying: the code is comprehensible, with appropriate names for classes, variables and methods.

I’d go further to say that code that follows these rules will help new people not only understand the code more quickly, but also the business. To use an analogy: The abstractions of the code, in terms of interfaces, abstract classes etc may well describe the most important core concepts of the business they are used in, whereas implementations of interfaces and extensions of abstract classes go down into the nitty-gritty details of the business, with all its nuances and special cases - quite simply, good code will help newbies in an organization to quickly get to grips with the business, and then drill down into the details!

People have a constant need to find a meaning in their own behaviour, historic events, events around them and in their lives.
This need to find a “reason” means that people will often try to find meaning in places that have no meaning.
It also means that people will backwards rationalize their own acts and wants: they often do this by arguing for their actions in a way that is something like “I did X, because I wanted to achieve Y, which is obviously a good thing”. In actuality the rationalization process subconsciously at the time the person did X might have been something like “I want to do X”. Simply put, there was no ulterior motive, but the action alone did not sound rational or noble enough on its own, so the person in question backwards rationalized a reason after the fact, which he himself eventually buys into.

We, as humans do this sort of backwards rationalization all the time, all day long: we do it with history, we do it with our own lives, we do it with our own behaviour. “I failed because..”, “I succeeded because..” and so on, and so forth.
We just seem to refuse to acknowledge that sometimes, there may be no grander scheme of things behind events happening.
It might just be that both history and our own lives are sometimes more influenced by pure randomness than any conscious choice or rational strategy.
Sometimes, there simply is no meaning or purpose behind what happens.
Sometimes, life is just what happens around us while we are busy planning.

I usually keep politics somewhat off this blog, but whenever I think of something supremely bizarre, I just can’t help myself.
Apparently, in the “War on Terrorism”(tm) we should accept having our liberties encroached in the name of security.
So here are a few questions/thoughts:

Airports are pretty much the flagships of security thinking, you cannot find an environment that is better controlled. Yet the security is counterintuitive and outright stupid: Apparently, liquids can be dangerous if an individual carries more than 3dl of it, split into three 1dl containers. So what if a couple of friends, God forbid, decide to cooperate and bring 3dl each, that they then pour into a 6dl container they buy in the tax free shops on the other side of the security?
And if mineral water can be lethal when carried through security, why can I buy copious amounts of flammable and explosive chemicals in the airport pharmacy at the otherside of the security checks?

Inconsistent and porous security anyone? And do keep in mind, airports are very much the “flagships” of post 9/11-security thinking. You won’t be any “safer” anywhere else.

But hey, I’m repeating myself, my main point is that security is very much reactive, based on politicians wanting to be perceived as “doing something”. They only stop one avenue of potential attack after it has already been attempted. But for each avenue of attack they close down, there remains an infinite number of other potential avenues of attack for terrorists.

I think the gist of my argument can be boiled down to the following:
Why would anyone in their right mind think that the same politicians and bureaucrats that cannot even catch obvious cases of benefit fraud made by semi-retarded rednecks, would somehow turn into James Bond-like superheroes just because you give them a gun and some wiretap equipment?

This post is somewhat related to a post I wrote the other week.

One of the most common mistakes tech startups do is that they become obsessed with perfecting their product, and delay their release over and over. It’s a mistake I did when I was running a startup, so I should know.

The obvious solution to this mistake is to release as early as possibly, and release the smallest subset of functionality for the product that is meaningful in some way, so that early adopters can start using the product and give valuable feedback (fact: most successful startups don’t end up with the same business model the originally envisaged).
But this doesn’t mean that a product should be pushed through in haste, with hacks, bad quality and all that it brings with it, even though it might result in a valuable early launch, it will come back and bite you hard eventually, if not immediately through disappointed and disillusioned clients who no longer trust you.

Even if you do get away with pushing something bad and hacky out the door at first, it will bite you whenever the product needs to be extended, improved and refined, because the quality will be so bad that doing these things will take forever, if they are at all possible. Bad initial quality is what either makes companies go under, or if they have enough resources and insight to recover, puts them in the money pit that is the endless “rewrite” project.
The emphasis on an early release is an important one, but the moral of the story is that to be successful, an early release should only compromise on scope of the product, never ever on quality.

I’ve had my current laptop since May, and I really love it, the size, the power, almost everything about it is great. Except the OS.

Windows Vista is littered with problems: applications freeze and crash regularly (I believe I had 20 odd application crashes on Thursday, including mundane things like WinZip!), it is slow, processes regularly go haywire and take up 100% CPU and 1GB+ memory, not even copy-paste works properly (ever)! It is simply untenable and frustrating.

So pretty soon, I will try installing Ubuntu Linux instead, I’m just sick of Vista, it is a major step back from the frustrating experience that is Windows XP.
Basically I only have two applications that I cannot replace on Linux: iTunes (I have about 4gb of music bought on iTunes), and eFax, for scanning and faxing documents. Everything else can be replaced.
Since I am also using my laptop for the project for my current client, and their platform has some build-time dependencies on Windows (bad, I know), I will also have to hold off for a while to see if the project will use the specific parts that have Windows dependencies.
But on the whole, I think my remaining small dependencies on Windows can be met by reinstalling XP on my old laptop (if I can only find the CD..), for the remaining 98% of my work, I’m pretty sure I will be Linux based from the end of October on..

..when both of their websites are filled with corporate marketing speech, but the actual downloads are buried and hidden away so that it is nigh on impossible to find them..

After almost ten years in the software development industry, I am no longer surprised by the utter lack of discipline in the industry, yet it is something that bothers me to no end. Compared to a lot of other disciplines, the difference in the level of consistent good practices and habits is mindboggling: Where a neurosurgeon would never get away with doing brain surgery with shaky hands and a big ol’ butchers knife as a scalpel, software developers not only get away with similar levels of indiscipline, many will even sigh in frustration at the suggestion that things should be done in a more disciplined way and expect to continue doing the equivalent of brain surgery with a blunt butchers knife.

It is important to realize that I am not talking about weighing developers down with more “formal” project management processes, in the same way that I don’t think a brain surgeon would benefit from having a hospital administrator telling them how to perform brain surgery. What I am talking about is embracing practices that have been proven to improve the quality of software, but that may not give much gratification on day one, hour one.

One such thing, and in my opinion perhaps the most important one is unit testing. A lot of organizations pay lip service to unit testing, saying that they think it is a good idea and that development should be test driven. Yet most of the time, unit tests shine with their complete absense, and if they are used, developers will be pressured to “just do something that works and skip unit tests” if under time pressure.
It just never seems to occur to a lot of people that unit tests will actually save a lot of time down the line in testing, regression testing, ability to improve existing code quickly and making dependendence on specific individuals smaller.

I’m only using unit tests as one example out of many, but my point is, that there are a number of “practices” developers can use, and that can be enforced to a certain degree that would improve the quality of software exponentially.
Yet with all this being known, a lot of developers will still be so set in their ways that they will expect to be able to continue having their old, bad habits, delivering shoddy quality, all with the ignorant blessing of management.

It is the product of an industry that is marinated in complacency, haste, ignorance and self-denial about its own state from top to bottom.

I have come across a number of JVM oddities today, courtesy of me having developed on 1.6 for the last week or so, but actually having to target Java 1.5, and thus doing a build again with Java 1.5, some of the more eye-catching are:

• The order of two elements in a list returned by some code got reversed. A unit-test caught this, the same unit-test I have run under 1.6 probably hundreds of times over the last week or so. I never got around to figuring the cause out, but it made me a bit perplexed until I figured that the expected order had simply been reversed under 1.5
•  Using Reflection and Lists using generics: not a 1.6-1.5 issue as such, more an issue with Generics it seems: trying to use reflection to set a list that uses generics on another object expecting the same type of list throws an Exception. Only workaround I’ve found is to check for Collection/List type objects when setting with reflection, and in the case of a list setting the method parameters explicitly with List.class rather than listObject.getClass().

Both of this things had me scratching my head for a few minutes, until I realized that they where somehow peculiarities to either the JVM version, or features of the language I was using.