simonsays

The Growing Irrelevance Of Java Architecture

2009-01-29T12:19:00.004+11:00

I was lately involved with a bunch of architects, in discussing standards for a Enterprise Java environment. Trust me, a fruitless exercise. People bickering about their favourite frameworks, why to use Axis over Spring-WS, why everyone should use maven style dependency management, maven is the devil, etc, etc. I have become accustomed to this behaviour and I do have a few frameworks I like myself..i guess it's just natural.

The thing is that after all the years I've been around coding and watching other people code, I have yet to see two projects using Java that use the exactly same set of frameworks with the same versions. So if the Java world can't standardize on anything, how come we are so busy attempting to try? The OS framework question seems to be the most contentious area when trying to get a few developers to agree. Some sensible people like to use less and be less prescriptive, but more often I find my fellow architects to be fierce missionaries that know only one god.

This brings up the question where are we? In the late 90s we had only Sun, then we had Sun standards and commercial servers implementing them, followed by the open source movement in the early 2000s that did everything different. Suddenly there was a free alternative for everything that could be plugged in, and people did. Then we had lots of W3C standards and the JCP. Sun was now reintroducing OS into Java and has been doing it for a while. Frankly I believe it's beginning to show. A quick look on wikipedia reveals the following: In 1999, J2EE 1.2 consisted of 10 APIs, 2001 brings us 1.3 with 13 APIs, 2003 we have 20 in release 1.4 and in 2006 there are 28! APIs to implement for a Java EE container, with a plethora of them only dealing with XML. This of course doesn't even try to count the OS frameworks which have bloomed everywhere like colorful cryptic little species. The only person I know who found this a little weird at that time already is Hani, so my hat off to him here.

Are you still keeping up? I admit that these days I have no idea what things like JAXR or StaX are, but I'm sure that if the official EE stack inflates any further, it's usefulness will reduce exponentially. All these things naturally version and age, and where I come from, binding to them and a particular container should be considered harmful if you love being able to upgrade or just like your simple CRUD. In this context, it is not surprising the first attempt at Java EE6 failed and the JSR was cancelled. So if Sun can't keep up in doing it and the JCP can't either, this bears the question again. Why are we trying to standardize so hard? Anyone still believe it's going to get easier?

Now that we have OSS, I can see similar attempts being made by corporates in that space (standards and versions). But no matter how hard I have seen people try (policies, maven, ivy), typically the latest version of the developers current favourite is adopted aggressively and early. OSS has become a huge commodity and nobody is allowed to take the developers favourite toys away.

If we are honest to ourselves, most of the APIs and OS frameworks in question are just busy talking to other APIs internally anyway. Taking a step back, what is the use of this discussion, even for an integration technology like Java? Our problems can't possibly have become more complex at this rate in the last 10 years now? If the main concern is the internal composition of an application, it doesn't really focus on getting a better result. Rails has taken off as a result and tried to fill a void with something that just works. Other software stacks are also less concerned with their internal composition and the environment, they just exist happily the way they are (i.e. LAMP).

So what are we left with? I guess as far as Sun is concerned an increasingly complicated set of APIs that will distance themselves further from real world problems with time. The OSS space seems to be reasonably stable these days (or boring compared to 2003 if you want), at least I haven't seen too many people that felt a compelling need to write yet another MVC framework lately. There are of course updates, and there are simply too many options for doing the same thing already. I guess not too many people will argue with that one.

In closing, do you think JEE can be saved from becoming the next dinosaur? Does architecture still matter or should it carry that name anymore? I haven't heard the words Java and legacy uttered in one sentence yet (in absence of a sexy new alternative probably), but realisticly, looking at the brittleness and convolution JEE is dealing with, how far away from that are we?

This week's SPAM review

2008-08-23T15:31:00.003+10:00

Ludek Dimovski writes me today, advising that Paris Hilton seeks Australian Residence. Unfortunately Gmail thinks that Ludek is not who he claims to be, so I probably should go tell dear Paris she needs a new character witness for her visa application. Salmon Blount joins our conversation and insists "Aliens Deny Impregnating Paris Hilton"; thank you Salmon, I too have high hopes there is intelligent life out there.

On to Swiss Watches. After reading several tempting offers from replikkk and miracuole.com, I can't make up my mind which quality product to choose. A quick check on Google reveals there is help. The good folks at replicawatchesreviews.com and fakereviews.com host detailed reviews for everything from cheap italian to $739 swiss forgeries. Comforting to know, the internet is there to help unwitting consumers navigating the minefields of e-commerce yet again.

Marisela Dacia has free Viagra for me. Maybe it will help me getting worth any girl's attention as Rachelle Dahl seems to think. Rachelle has the better business offer though: permanent enlargement of my vital parts, just using a different type of pill. Ahh, so many choices.

Alva Alba suggests I call her and leave my name, number and country on her voicemail so she can get my "PhDD" ready asap. Sorry Alva, I'm a little busy this week, maybe next time. I hear these things are long and complicated, and I thought I'll give you a head start - better get cracking. Also what happened to your sister Jessica? She wrote me all these emails but never replied to a single of mine?

Finally my good friend Brandyn Tabot is checking in to tell me that Paris is almost bankrupt...you don't say Brandyn, maybe I should contact border security about her after all.

Agile project management adoption trouble

2007-05-09T21:12:00.000+10:00

I've been wondering why it is so hard to get an agile methodology adopted by any project. I am speaking merely from my own anecdotal experience, this does not claim to be of any broader relevance. My own background for the last year is in consulting and after reading a few books on agile and talking to customers, bosses, and our competition Thoughtworks in Sydney on multiple occasions, I had sort of arrived at the conclusion that this is a killer methodology. After all the customer gets what they really want, the developers don't stress out, quality is better, and the project moves at a sustainable rate towards it's goal, right? All peachy? Not really.... I've found a lot of road blocks in establishing this kind of project management methodology and I was sincerely thinking I'm trying to do people a favor. It turns out I was being a bit naive, maybe. Here's what I experienced.

Agile planning takes longer than guestimation.
"Are we there yet?" This line from a 6 year old kid in the back of the car is what you can expect from your customer in the quotation phase. There is zero tolerance for wait while you do your work and there is definitely little cooperation. After all there are all these different vendors to choose from by your customer. Which one are they going to pick? The one that takes 3 weeks and 4 feature workshops to just do the planning (and they want to be paid for that too!), or the one who is ready to issue a quote based on a one liner? The prospect of a lengthy planning phase that is also taking place before the whole (preferably waterfall style) project is signed is somewhat unappealing to them. Why would your customer worry about agile estimation? It takes too long and then the plans aren't final anyway? So why bother? As short sighted as this may sound, have you ever been beaten by the guys that were just a little quicker than you and took a few shortcuts? Exactly! The fact that they are probably going to screw up some of the work doesn't matter at that moment because they got the deal and you don't.

Some customers just don't want to be involved.
Another thing I find is, that you have to deal with an increasing number of people that really just want to purchase. This also goes for complex solutions that take require planning, some level of prior thinking and alot of money. You could say consumerism has fully taken over the corporate world, and off the shelf products are acceptable as solutions for complex problems. After all from a vendor product you do get all that support and their whole organization backing it, right? Especially when the customer doesn't know what exactly their problem is, I find them more prone to choose a ready made product over going through the trouble of specifying requirements for a complex solution with you! What sounds great in theory about iterative methodologies is the involved customer. I actually find them rather hard to spot out there. One thing your customer will never tell you, is that he is paying you so he doesn't have to do any work. Hey, why would he do that? He's got the money to pay you after all! So in order of preference for them, I'd rate three vendor candidates for any potential customer as follows:

1) Gives me something ready, I don't have to do a thing.
2) Is ready to tailor me something based on a more or less vague description.
3) Makes me do work in order for him to be able to do his.

On top of that your new methodology shifts some of the responsibility and risk back to the customer - and we wouldn't want that.

Customers don't like to be challenged on the way they do their work.
Next to actually having to do work, the customer is facing another problem. This one may be more serious, depending on whom you're dealing with. By introducing a new project management methodology, or even just trying to do so, you have just told your customer he's been doing his job wrong for all this time. Chances are, they are not going to take that well. A lot of corporate environments I come into as a consultant even pride themselves on their highly formalized, waterfall style project management. Of course it will rarely carry that very name (though I have to admit I have actually had to work with something called 'waterfall 2006' last year), but you can usually spot it easily by the amount of templates it requires you to fill in and the numerous prescribed steps you have to go through in exactly that sequence. I visited a large retailer a couple of weeks ago that was very proud that 80% of their projects arrive in time, on budget and with all their planned features. Can you believe that? Only if you're in the business of seriously fooling yourself, methinks.

Next to not liking to hear that they are doing it wrong, you are also most likely to not be alone with your idea of new ways of project management with your customer. There are a myriad of things out there, Prince2, Six Sigma, etc, etc. Explain to someone that is already dealing with information overload in project management methodologies and "just wants to get the job done" why they would pick yours. You'll get about one minute to explain and then they will tell you something like "yeah we already do that and ours is called XYZ". You have just been hooked onto the next waterfall gig. After all if it's their *own* methodology, who are you to argue with that?

Agile still has a reputation as a chaotic, "no planning" hacker methodology.
If all that hasn't scared your customer away yet and they actually heard of agile, chances are good you will get some feedback like this. "Ok, I heard about this agile methodology and it's really chaotic and says you shouldn't do any planning". Nothing could be further from the truth of course but that seems to be the general perception from people in waterfall land. Agile - crazy, hacky, chaotic and worst of all - development centric. If you think of it from that point of view it's no big surprise business people don't like it very much, that old rift still exists.

Funding models for projects aren't friendly towards iterations.
If you've made it to this step, you've already done pretty well. Your customer wants to do it, they think you can do it and they also trust you to pull it off. However chances are you will still be killed off in favor of someone who does it in one go. I'm talking about fixed price contract development. You will find that most companies have funding models based on one time allocation for projects. This kind of budget allocation is now pretty standard and designed to counter these never-ending, overpromising IT projects we've all heard of so much. Once your customer has the money allocated (and after some bad boy has given them the cheapest fixed price quote) they can't exceed it and also have to spend it in a certain time frame. Now even if your direct customer wants to do business with you the agile way, his CFO might not and give the contract to some other vendor rids him of all that uncertainty. This is when things get nasty. If you watched Al Gore's superb "inconvenient truth", there is a part in the movie where Gore talks about how hard it is to convince someone that something is right if their own salary depends on the opposite circumstances. From a funding point of view your customer has nothing to gain. If it's fixed price it's fixed. If it's variable price and it takes less time, the customer knows you're not going to wrap early, but stick around til the allocated time is reached. If it's variable time and it goes over budget it's his problem. If it's fixed price and goes over budget it's yours! Fixed price = they always win.

All that being said, there seems to be a general hostility I sense towards adopting agile practices. This may be largely motivated by lazyness, ignorance and the fact that people don't like to challenge the status quo among peers, however it remains strong. If I sound disillusioned, i am not. Despite of having to deal with some of the more ugly issues I am more curious how to work around them.

But what do you do as long as it's OK for some outsourced projects to arrive partially complete but on time, arrive highly documented but hardly functional, arrive non-functional, delivering no value, but having successfully stuck to the process, or fail alltogether and it doesn't matter because after all you can sue the vendor you've outsourced them to anyway?

4 Weeks Of Introducing A Wiki Into An Organisation

2007-03-16T19:48:00.000+11:00

I have a great new job. Well it's not really my official job, but I do it anyway - I'm trying to get a wiki adopted by our organisation. We're a small consultancy, about 50 people, most of them not in the digerati age bracket. People you'd find working in an office, going about their day to day jobs. About 15 full time staff and 35 consultants "out there". For the past 4 weeks, I've had quite a ride getting confluence approved, installed and most importantly - used! While I wouldn't dare to declare the operation a total success yet, I wanted to share this month with you and the things I've learned about how to introduce a wiki and a few tricks here and there that helped me getting an at least semi-loyal following into the wiki world. I should probably wait another 4 weeks and write another one of these (hey I might!).

Like in many other organisations our internal information flow is gooey, sticky stuff. We use shared drives and email - needless to say both suck. The shared drives aren't accessible to the consultants in the field and even to the internal staff they prove of limited use. The main gripe people have is that they aren't searchable and some have found local workarounds of the likes of google desktop or Microsoft Desktop search indexing the shared drive contents. Of course that makes stuff a little easier to find but we still have the versioning problem and much more the accessibility - people without a VPN connection can't get to things from outside the office. People share information by emailing word, excel and pdf documents around the office. "Read that document? Which version? Bob's version? Who's Bob?" (sound familiar?)

I decided on the wiki because I knew we could do better. I knew that because I have seen it work. Now how was I going to superimpose a new way of working to 50 unsuspecting guinea pigs?

Lesson #1 - Pick a target
No matter what you think, you are not going to change the world overnight. The same goes for a team, even if it's not a big one. My strategy for adoption was going to be one by one. The first "one" was a new project that just had emerged. After installing the wiki I basically walked into the customer kick off meeting and pulled out the confluence meeting agenda page before anyone could really say hi. I said that I realized everyone's time was precious and that we wouldn't have a chance of doing this everyday. Then I pointed at the agenda page, changed a few things, did a 1 minute edit and left a bunch of business cards on the table, remarking that everyone should email me if they wanted in, while promising project content to be available there. I got 2 minutes of airtime before I felt I was about to be "taken down" and I rolled the presentation up. Earned some weird looks but got 4 customer emails within 2 days. Success!

The other one by one target were going to be my workmates. Pick one person, give them a walkthrough, show them what's out there, create an account and ask them to help me change things and maintain common information. With confluence you also get personal spaces, and after I realized that every future convert I was talking to was especially interested in the people directory, I made a habit of setting up personal spaces with real pictures of people as I walked my new users through what confluence does. With every new face in the people directory, the "ah" effect of looking at it from a newcomers perspective seemed to be bigger. I always took new snapshots with my Mac, not using CV pictures, they just look more real and as if the people were actually in the wiki. Mental note: casual pictures are good for an informal information space. We now have around 10-12 picture profiles and people start putting up personal content such as baby pictures, dogs and their sailing yachts! Personal spaces proved to be a real killer as they helped spread the wiki through the existing social network.

Lesson #2 - Make your entry barriers low
But if that may sound like early success - my job is far from being over. How does this wiki notation work? Do i make a page or a space? Who can see this information? Is this secure? What do I put where? The confusion going on about a new medium like this wasn't going to be settled easily. Aiming low was always going to be one of my goals, yet I had no idea how low I would go - introducing a wiki proved to be quite a limbo dance competition ;) One of the first things I've learned is that it has to work instantly - and because people aren't happy editing pretty polished things that look ready, I made a point of going to the test space first and demo. "yes you can change things and that's cool". It earned me some points on things being easy, but I sensed a general feeling of "inappropriateness" in my target audience when it came to changing what other people have put up. This one was not going to be an easy one. A few things I have learned about wikis(confluence) and entry barriers in particular:

a) Use Wysiwig editing and don't show wiki markup too soon. The "digerati" folk will figure it out soon enough, the rest *don't want to see it*. "Eek we have to program".

b) Set up a space email address people can mail. Something people do naturally is email - even your non users (which of course you have created accounts for anyway) will cc a project email and make things available to the group without knowing how it worked.

c) Set up WEBDAV - it is a total killer. In confluence you can save attachments to webdav if the proper plugin is installed. Make sure to map a windows web folder on everyone's desktop so they can save files into the wiki. Now this has proven to be the most useful entry barrier we have lowered. People can update wiki attachments without knowing it! Let your key people decide what content goes up and make sure the rest has the windows web folders mapped to the right place. Sooner or later everyone's going to build the mental bridge between the wiki page structure and the good old shared folder. It still feels like a shared drive yet it feeds into the new wiki crowd. You gotta *love* WEBDAV.

Lesson #3 - Seed content
By now we might have shared folder love and a few early adopters but we still need a reason to go to the wiki on a regular basis. Choose your seed content and your structure carefully, based on whom your target audience is. Don't do too much or the wiki will look like your personal little empire. don't change and reorganize everything people contribute, it will make them feel insecure about doing it again - even if it wasn't in what you think is the right place. Also choose some exclusive content that is layed out nicely which will only appear in the wiki. In our case I put social events pictures up there and asked someone else to email a notice to everyone that they had found them there. Within 1 day, I got 10 emails requesting login accounts. Exclusive content works!

Another thing we did is convert the internal phone list from excel to a confluence page. Within a few days people started updating it because it was easy (could be done in wysiwyg). Seed content needs to be useful and make life significantly easier.

Lesson #4 Show them the future
Even though not everyone might be comfortable with it at first people want to go on a journey. Have sexy pages, do advanced formatting or macros of the likes of IM status pages, google maps and calendars. They spice things up and allow people to go "wow". If they see the unexpected, they are more likely to give things a try and come up with stuff of their own that could actually be really useful to the team. You need to excite your key people, they will become your ambassadors.

So far we have reached out to about 30% of our staff, I've won a few key people but we haven't reached critical mass yet. I hope we will make it. Let me know your wiki adoption stories, I'll post a follow up next month.

Invasion of the MacBook Bodysnatchers!

2007-03-01T15:33:00.000+11:00

Ever noticed how MacBooks are appearing out of nowhere in cubicles near you? With every passing day I feel more like being the star of "Invasion Of the Bodysnatchers" (and that is a scary thing if you've watched that 70's flick). The Mac has definitely shed it's image of being a geek toy and is making headway into the mainstream - fast!

Remember when Dell laptops were cool? It must have been only a few years ago. Hold them next to a 17" MacBook today and tell me who's going to pick the Dell? Any takers? ... I didn't think so. (Now someone go tell the makers of the Stargate TV shows!)

Now I am writing this because I couldn't escape and I have officially been snatched up by the Apple folk. This is the first blog entry written from my shiny new MacBook and thanks to the backlit keyboard I can do some of this in the dark. Unix shell, fast windowing, no bluescreens, no viruses, quicksilver, sleek design - it is a thing of beauty. What was I thinking all this time before?

Watch out for the MacBook converts, it's addictive!

Jira Cubicle Edition

2006-09-01T14:04:00.000+10:00

long time no updates (March!), I'm getting sloppy on the good old blog so I thought it's about time to share this one.

Unfortunately I didn't get Jira approved at my current job, and we have to use both TestDirector and Bugtrack. Sigh, Yeah I know, but hey you can only lead the horse to the water... Anyways I decided I need a better way to track my day to day issues and put this one together pretty quickly. Since I borrowed a few ideas from the guys at Atlassian, I decided to add a small name tag at the top right and suddenly people in the team started to refer to my little wall of issues as "Jira" :) So far (~3 months) I have to say the XP style cards work surprisingly well for me, the best thing about it being the immediacy of you knowing what you're working on with a single look up from your desk.

Just like in real Jira the yellow issues are tasks, green is for features, blue are improvements and red are bugs, lined up in a column each. I leave only open issues up on the Jira wall and take them down immediately once the code is checked in and tested. The cubicle wall accomodates around 25 issues at once which is a good limit for general developer sanity, if it gets too busy I know it's time to turn down new work requests.

I have tried taking pictures of the wall with my pda phone before going to status update meetings and while you can't say reading the cards is possible on that resolution their position shape and color, strangely enough, *do* remind me of what I'm working on :)

You'll also notice the "toolbar" at the bottom - a more obscure issue wizard which still has to prove it's use :), the "add issue" coffee cup which holds the pins, markers and cards, and the "closed issues" cup, which is where issues go when they're done. Usually at night after work, they're moved over to the clip on the right which resembles the change log for an iteration.

All in all not too much effort, just takes a bit of discipline and a good ongoing supply of stationary (thanks Toni!). Jira cubicle edition comes as a DIY kit around $25 and will fit most cubicles.

Industry Professional Deformations

2006-03-10T20:04:00.000+11:00

You may or may not be aware of your professional deformations as an engineer, but they most likely includes tendencies of overengineering, analysis paralsys for architects, poor people skills because of the amount of time spent with machines, and getting quickly frustrated while bugfixing the relationship with your girlfriend. It's not every single engineer, but if you look at alot of different subtypes, you will see the common methods inherited from somewhere elusive :)

The good news is we are not alone. I'm now working for a large insurance company (as a consultant this time) and in my fourth week, I am beginning to figure out how these people have their particular way of doing everything they touch - the insurance way. So no matter if they start a new project, a bugfix release, an OH&S briefing, or plan a night out in town, everything unknown is a potential *risk*, because that's what insurance does - risk assessment. That's right folks, where other people see a project opportunity, here with suddenly talk about everything that could go wrong before the business benefit can be realized.

I'm not talking simple Murphy's law here, you gotta have a backout plan if you get it wrong, so they can go back to the old one. If you happen to get it right, you need to provide a business continuity plan, in the event it goes off the air. In all cases, you talk to the IT risk analyst, who regularly assesses your project for technical, business, budget, people and methodology risk! Makes me wonder how they ever get a foot out the door?

In my previous job (Telco), every project had to have a security review, firewalls, redundant servers and service level agreement and was basically treated like a network. Now everything is treated as a calculated risk which needs mitigation.

I hear banks budget everything and investment banks screen every company they work with.

We all already know that Consulting firms talk&sell too much :)

Are we all victim of what we have been doing for too long?

How is your industry a little funny?

Interview Questions, Part Deux

2006-02-02T18:28:00.000+11:00

Since under circumstances unknown to me, I ended up on the javalobby front page (I almost feel like Bob Lee), let me clarify why I listed those particular beauties. They have all proven popular, yet a little funny. Try answering the StringBuffer question the nth time without having to cringe and you'll know what I mean. They're funny because they are are either overly simplistic, incorporate a word game unrelated to the skill in question, or they reveal things about your interviewer he probably wouldn't want you to know. They make me wonder why they're there, despite that, I get asked them alot.

Which leaves us with - how *do* you classify job interview questions, and how do you tell the good ones from the bad ones? Well I'd say that highly depends on what kind of person you aim at (not) hiring and what you are trying to achieve by asking. Want to figure out if they know something? Want to intimidate or stress them? Want to see whether they're lying? Here's an attempt at classification, without assumption of being complete. I'll try commenting from both sides, interviewer and candidate.

Yes/No questions. As a candidate, I find those pretty pointless, but you get them alot. "Have you worked with xml?" You answer with your most convincing "yes" or more embarrasing "I've heard of it" and that's it. The interviewer can't possibly learn anything interesting about your skills, but the reason for asking might be the scattered technology landscape and even interviewers being confused what exact mix of skills to hire. They end up ticking off points on a list and selecting the candidate with the highest match rate (which was most probably a liar). Recruitment agents are big on this, and at my previous workplace we had the ongoing joke about "how many lines of string matching code replaces a recruitment agent?" (Not many apparently, thanks to regex).
Prohibitive questions. The interviewer lets the poor, sweating candidate on the opposite chair know he expects him to know this one (interviews can be such brutal mind games). "Let's start with an easy one" The candidate gets nervous and forgets what he wanted to say, even if he might have known the answer. The interviewer then marks the candidate off for darwinistic selection. These killer questions are used to weed out candidates and do their job most effectively, if not even a bit too effective.
A similar category, popular with development jobs are RTFM questions. "List the names of all Exceptions in the foo() method of Bar.class". You'll find myriads of these. The database guys ask SQL questions until you stumble, the "old school" developers dwell on bit-shifting operators, and the worst offenders, I call them the vendor drones, ask you smilingly "how do you achieve "bar" in "vendor foo 1.2.3", but not the simple way it's written in the manual?" It's obvious that even in the unlikely event of the candidate sleeping with the manual under his pillow, and the solution having diffused through his skin, directly into his brain, his ability to answer this one correctly will not automatically enable him to perform better at the new job. The interviewer knows this, but enjoys his machiavellian moment of triumph anyway.

To take off the pressure of such questions, the candidate needs to learn the power of saying "I don't know", then offering a solution on how he might find out. Yes, you can let your interviewer know you think he's a moron, it works!
Open ended questions - get the candiate to say a few lines, put him at ease, and observe how he handles himself. While conducting interviews I found these the most interesting ones to ask. I now also begin to like them as a reborn candidate because it can be a nice way to differentiate yourself from other people. There still seems to be a widespread brain imprint about all software developers being pasty, pimple faced nerds without girlfriends that make only star trek jokes. Go out there and convince them of the opposite, without going overboard with the self marketing and you'll leave a lasting impression.

So how do you ask good questions as an interviewer? Probably create a strategy about what you want to find out and then find a good mix between technical detail and general impression. Let the candidate know what you are after and give them the room for filling out that particular space.

As candidates....practice practice practice, you will get the hang of the mots du jour, may they seem sensible or not. And then once you're in... who cares?

Writing unit tests after that feel like tests before

2005-09-26T09:40:00.000+10:00

Ok, I tried the following method for writing tests afterwards, that truly stands up to unit tests written by the book, meaning test first before you implement.

1) Choose a problem and start hacking away with the interfaces and a bit of the implementation, preferably from 3pm on so you can enjoy a nice late afternoon/evening of coding. After a few hours, you'll notice you'll get slightly tired but very relaxed about the implementation. You have now entered the coding zone. Keystrokes flow effortlessly and you know why god made you an alpha programmer. Chances are you will find a neat and interesting subproblem and get stuck on it for the rest of the evening. Pizza and coke at 7pm will sedate your brain effectively and prevent it from applying unnecesary self criticism.

2) At about 9pm, ring a few mates and rally them for beers. Leave the laptop at work and hit the pub, where you start exchanging war stories. At this stage it is imperative you wipe your brain clean of all implementation details, so you achieve a higher state of being you could describe as "interface clear", to borrow a term from scientology. I recommend a few James Squire's Pilsner pints, maybe followed by a fine single Malt to round things up. Make sure to divert the conversation from coding, recommended is discussing efficient new ways of solving sudokus with your mates. The warm and fuzzy feeling you enjoy thanks to the single malt will give you unprecedented insights into this bizzare, irrevelant, yet strikingly interesting world of numbers.

3) You wake up the next morning, not knowing how or when you got home and you remember a faint dream about walking down a road made up of pi digits. Roll out of bed carefully sideways and thank yourself for leaving the laptop at work so you won't have to carry it there. Order a double espresso at the italian and throw in an Aspirin, if required. You are now fit to test code! After having arrived at work, take a look at your interfaces, however no matter how tempting it is, don't look at the implementation. A voice inside your head goes "did I write this?" - which means you have done it. Fear not, code away with those tests without even knowing what the problem was you were trying to solve and it will dawn on you again, bit by bit, as the alcohol slowly leaves your system.

You have just practiced exxxtreme programming - your tests are guaranteed not to be influenced by your implementation in any negative way. They are also most certainly failing the first time you'll run them. For various reasons You wish you had a programmer to pair with, however judging by your smell for the day that may continue not be your wish. Finally you are guaranteed to only change one thing at a time before recompiling and integrating, because that's absolutely all you are physically capable of.

Software Craftsmanship

2005-09-20T10:23:00.000+10:00

Attended an interesting discussion last night about Software Engineering being art as opposed to science. The discussion was based on a collection of (behavioral) patterns published by Dave Hoover and Adewale Oshineye, titled "From Apprentice to Journeyman guidance for the aspiring software craftsman" Local thoughtworker Darragh Farrell presented the patterns to the group and opened them for discussion.

The term software craftsmanship according to Dave, represents a value system that focuses on the practice, as opposed to the university taught theory and has a focus on the individuals accomplishment and progress in the "trade" of software engineering.

I won't go into all of the patterns, however there are some striking similarities between the profession of writing code and other trades.

There seems to be a high level of job satisfaction associated with creating something that is tangible and of direct use to others.
Craftsmen tend to like what they do and would do it for free anyway. Their primary focus is to become better at what they enjoy doing, not the money which is involved. Most people tended to agree with that, and someone even stated "the more you pay someone to program something, the less they want to do it" or "I don't know any accountants that go to Geek Nights doing the books".
The search for beauty in the craft seems to be another important driver. People drew some interesting similarities between the common tendency of overengineering a solution for the sheer joy of it and an artist in the classic sense and his attention to detail and beauty. One of Dave's patterns, "nurture your passion", even suggests to actively seek out tasks that keep your passion alive, especially when exposed to an otherwise professionally boring environment. Some people argued this is why open source software exists in the first place as a means to vent creative energy otherwise unused.
The "Draw your own map" pattern suggests that being craftsman, you start having a career plan which details how you advance over time, where to go and what to master. The general concensus seemed to be that this is awfully hard in IT, with the ever changing technology making planning close to impossible and also the fact by the time you are old and wise enough to be a master, something very well accepted in the classic trades, being 40 years old in IT you are just a little bit out of fashion. I could not resist thinking "Fortran Master", apparently I was thinking out loud, because everyone started laughing at me. Jason Yip's take at this seemed to be more along the lines of "go with the flow, good things will start to happen around you". Overall I could sense a degree of hesitation when it came to planning one's career. Most people seemed to agree that software development lacks a an accepted career path you can progress for life.

For me, the subject was a definitely a fresh perspective, a new way of looking at what I do and it seemed to spark quite some interest with the crowd, based on their reactions. Interesting closing comment on the maturity of a software engineering trade, overheard after the talk "We're like the bridge builders in the middle ages. We build something, wait until the whole thing collapses, then we change the design and build another one".

I recommend reading the patterns, if you're interested in more.

Choosing a new job: career vs. fun

2005-08-27T14:03:00.000+10:00

So I'm 20 years old. In hex. Convert this to my real age and you'll probably agree I'm getting too old to make nerd jokes like this one. This is somewhat the heart of my current dilemma - deciding what to do with my career in IT. Do I choose a job that involves doing what I like or one that supports my career progression?

Where do I start? The last few years have been amazing. I've witnessed how the open source movement has changed the face of software forever. I was lucky enough to meet an amazing bunch of developers here in Sydney and have a small team of them at work in our project. I really love what I do and I still consider it a privilege to be paid for something I would do for fun anyway.

Nevertheless it's time for some change. Mainly because I feel I can't learn anything significant at my current workplace anymore, but there's also the odd career question to be asked. Where to go next. In my early thirties now, I have the inevitable decision whether I should move more into management or stay in technology and become a grey haired 40ish java programmer in 2015, a time where the word java will probably sound more like cobol today.

Over the past months I have witnessed people, even younger than myself, quitting their jobs to 'exit technology and go into business' - whatever that means exactly. So far, I have always considered this step more of a blurring of your profile, rather than a broadening of your range. Being passionate about development, I'm naturally worried about sinking in the sea of irrelevant powerpoint packs and corporate bullshit. Nevertheless everybody around me seems to be busy to get out of technology as fast as they can. Some are afraid of being offshored, others want to become part of the business club, others are sick of renewing their skills on an ongoing basis. A friend put it this way: being a lawyer you are at your professional peak at 40, in technology you're just a little bit out of fashion.

That much about the future and it's prospects, but planning the future seems to be a funny business these days anyway. Forecasts live three to six months, so let me get back to today. And in that world I basically have three options:

1) Go for an extremely lucrative J2EE project management gig. I can keep doing this for at least another 3-5 years. Very career friendly, horrible work hours, but maybe good fun, depending on the kind of project. I obviously can't spend as much time programming anymore, but I might get to pick some nice tasks and assign them to myself.

2) Stay in a large corporate and become a middle manager....yuk. Trade in some of the money for a bit of perceived stability. Sink in the sea of mediocrity....alright I think this one is out. Even in the large corporate I think i can't afford to keep doing what I am doing now else risk becoming "staff" in it's ugliest sense very soon.

3) Do something of my own and start a company. Now here's a bagful of possibilities I haven't really explored yet. Could be cool, could fail miserably. Career wise the biggest gamble, but definitely has heaps of potential. You want a good partner on this one for sure.

Since #2 is out I think it's going to be a bit of #1, hopefully followed by #3 soon. Let it rain a good idea please!

Dude ... where's your Gmail account?

2005-07-12T11:44:00.000+10:00

So according to Jason Yip using a hotmail account in public is embarrasing. "Do you need a Gmail invitation?". Original feedback from yesterday's Sydney Geek Beers. Sh33sh, I'm getting old huh?

TSSS for the rest of us

2005-03-15T06:02:00.000+11:00

last night, Mike Cannon-Brookes spoke at Sydney Geek Nite, giving us his presentation from this year's ServerSide symposium. Mike spoke about pluggable web applications and a framework for it, Atlassian have developed. His basic suggestion was, that every kind of application allows you to extend functionality these days, except for java webapps. Atlassian's framework is designed for helping developers build such extensions.

The plugins themselves are simply wrapped as jar files and contain a plugin descriptor with a unique name and version that identifies the plugin in front of the application. As far a visual plugins are concerned, they can contain velocity views (JSP won't work) and support custom classloading, so the plugin can be deployed at runtime.

Another interesting possibility is the injection of servlets and even webwork actions into the application, now here's a bagful of possibilites!

Mike's value proposition for the framework was that "even if you don't know what you have to integrate into next year, have a way of doing it".

The whole thing sounds very interesting, hope to see it open sourced as announced.

IntelliJ Irida Impressions

2005-03-11T16:55:00.000+11:00

As probably many of you who use Idea, I'm a huge fan of my IDE and often download the latest beta, seeing what it has to offer. So far, the quality of betas has been acceptable and I've been using some of the new features, and put up with the occasional crash.

Sadly this hasn't been the case with the Iridia builds of the last months. I encountered quite a few crashes which reminded me that my primary working tool should be simply....working. As a consequence I have reverted back to the latest stable 4.5 version which isn't as fancy looking, and also has a bit slower UI windowing components, but at least it doesn't die on me that often.
Things that put me off on Irida were:

I wasn't able to increase the heap size via -Xmx in the config file like in 4.5. This becomes very annoying if you have more than one project open and run out of memory quickly.
Debugging multithreaded apps causes flipflop behaviour on the IDEA debug window and has a tendency to freeze up the whole thing.
ANT buildfiles get shown as corrupted for no particular reason.
Breakpoints get rendered as invalid without reason.

The last one did it for me yesterday, if I can't debug properly I'm done! Sorry Jetbrains, now happily waiting for a stable final release which you have always managed to deliver.

Method names from hell

2005-03-10T23:28:00.000+11:00

So today I was sitting down with our contractor Conrad, trying to understand some of his designs in our ThreadManager when I came across this method in his test case:

testCreateDaemonChild()
//Read twice to get all the subtle meanings.

Let me assure you Conrad is not a satanist, but the team soon agreed this surely qualifies as a "method name from hell". Conrad of course plead innocent, justifying his choice of name with the class's purpose. Too late, and too good not to be blogged methinks :)

JMAGE 0.4 released and I'm sick of writing unit tests!

2005-01-06T10:34:00.000+11:00

Well, well, it's been ~3 months this time for a release but it's not because of the heaps of features that are new, 0.4 has really been a unit test writing hell - I am now officially sick of it. But hey on the positive side I fixed quite a few bugs by completing the tests for all core packages. Tests now total to 243 so I guess that should be a confidence boost for stability or something ;) I need to start some kind of issue tracking soon.

What's new this time:

introduced multithreading support. A pool of worker objects now services multithreaded requests for images, such as commonly found in webapps. This improves JMAGE performance, especially the ResourceManager that traditionally has to wait for I/O.
Major cache changes to accomodate worker object pooling. The cache now services a pool of clients as opposed to only one.
Lots of new unit tests for all org.jmage.* packages. I introduced JMOCK for all the interaction testing, which is a big help, even if it takes a while to write some of the tests.

With the backlog of writing tests out of the way, I should be able to pack a few more new features into 0.5, mainly:

SOAP-RPC client
Some new filters (shadow, others). Please submit ideas if you need a particular image filter.
I guess the jmage.xml finally needs a dtd.
if you want anything else in, drop me a line.

The Infringements List

2004-12-16T13:03:00.000+11:00

You all know them - infringements developers commit when programming. Stuff you all know you shouldn't be doing, but you're going for convenience and do it anyway. I am talking about shortcuts "just to test", hardcoded references, etc etc.

Why am I going on about this? Yesterday at the office, when planning what to do for the xmas party, it occured to me I need a good scheme to come up with some rounds of beers. So I started a "java infringemens list", printed it and put it up on the wall. At first I earned some weird looks, but then we had a good laugh at it. We now also count the offenses on the whiteboard. Everyone who gets caught with their pants down gets a tick and voila - here is my drinks scheme for Friday. As a side effect, I expect some refactoring going on the next few days :)

Here is some of my favourites:

Infringement	Fine
ClassPath related	1 beer
NullPointerException related	1 beer
System.out.println() usage for debug	1 beer
public static void main test code	1 beer
unit tests with bugs	1 beer
class not in same name file or wrong package struct	1 beer
com.MYPACKAGE.myClass or other capitalization offenses	1 beer
not reading error logs before asking others for help	1 beer
cut + paste code	1 beer
absolute references, i.e. new File("c:\myhome")	1 beer (2 beer if it works only on windows)
while(true) { … } or other infinite loops	2 beer
modifying code without version control turned on	2 beer

JMAGE 0.3 out

2004-10-18T13:28:00.000+10:00

After a busy week, I have released 0.3 of JMAGE. Here is what's new:

Tag library introduced. All simple filters now have a corresponding JSP tag. Filterchains can also be invoked using a special filterchain tag.
Added disk caching. While previously you could already cache the most popular images in memory, you can now specify type="memory" or "disk" in the jmage.xml file where you want your results cached.
Added caching to all FilterChainFactories. This is useful where you use long filterchains that previously needed to be deserialized from xml each time.
License changed to BSD (was GPL). I hope this makes it more friendly to integrate into your own project. Thanks to everyone at Sydney GeekNight who reminded me not to use GPL for open source.

The next few releases are probably going to see:

Multithreading support with worker threads.
Simple clustering so you can have your image rendering server in a webapp (experimental).
SOAPRequestMapper for web service invocation.
Some more caching tuning.

Can't really say when 0.4 is going to arrive, am currently very busy at work. This will also depend on how many people are actually interested in having JMAGE running in their webapps. So if you are out there and you are using it, I'd love to hear from you.

XP Zero Config Wireless Support

2004-09-28T13:35:00.000+10:00

Why is it that we still have this kind of feature? I'm sure a few of you will still remember how how plug& pray support was initially introduced into windows. The "i'm doing everything and free you of all worries" feature in the operating system tries to monopolize the installation process of newly added hardware, only to be interupted by "fancy-looking self installer with vendor hooks 5.0". In the end the component doesn't work, because after the inevitable reboot windows has tried to regain control.

Why am I writing about this? I spent a good share of last night in front of my new dell laptop trying to get wireless networking operational. Almost 10 years after plug and play, Microsoft decided to introduce yet another "I'm doing the thinking for you" component into windows, the XP Zero Configuration Wireless support. "Xtreme Configuration Zero Wireless Support" would do it more justice. Since SP2 my conventional 802.11g card driver refuses to work with windows zero config networking, even if that particular feature is switched off! Needless to say with zero config switched on and the custom driver disabled, networking doesn't go anywhere either. I'm fuming....why does Microsoft still write this kind of software? It should be clear by now that vendors *do* love to write their own little GUI installers with drivers. It gives them a sense of purpose. It shows the world that other company logos than the one from Redmond do exist in the software industry. As a side effect, it also lets you configure parameters you actually care about....oh well.

JMAGE 0.2 released

2004-09-20T13:48:00.000+10:00

After a few more minor fixes, I was able to release version 0.2 of JMAGE today. I can't count anymore how many bugs I fixed, but there were plenty. This release should be considered a stability improvement that brings the framework to a more useable state and includes only few new features. What's new anyway?

Cache system for resources and encoded images significantly improves performance.
JMAGE can now load resources from inside the web application, across containers.
Filters manage their own color band conversions as needed.
Wrote about 200 unit tests for all filters and supported image formats.
New NoOpFilter will be used as default modification instead of throwing Exception.
JMAGE should now be threadsafe.

At average rendering times of 2.5 seconds (with hardware support enabled), the cache makes a huge difference in getting your images to the client on time, and reduces this to a few milliseconds.

The upcoming 0.3 should see more new features, including taglib support, again performance improvements, and cascading filterchains (Yay!).

Sydney Bridge Run

2004-09-12T22:02:00.000+10:00

Did the Sydney Bridge Run today. For those of you who don't live in beautiful Sydney Australia, it's the only day every year where the Harbour Bridge, or the coathanger as we say here is closed off for traffic and you can run over it. What may sound like a breathtaking view for the 15,000 odd people at the start, actually turned out to be absolutely freezing cold and winds were strong enough to rip off the numbered sheets runners attach to their gear. Thank goodness it turned out sunnier at the Opera house where the race finished and where I met Mike and had a bit of chat. Finished the 10k in 55:15 which is not bad but not particularly good either, I always manage not to be 100% fit just before a race this year, a hidden talent of mine. Trying to go sub 50 minutes next time.

For the latter part of the race where GPS actually worked, here's what it had to say:

Sydney Bridge Run

My first attempt at dynamic proxies

2004-08-30T13:36:00.000+10:00

On the weekend, I tried dynamic proxies for the first time in a real world application. Having been aware of the technology for a while, I wondered what the hype was all about.

While writing a cache for an object factory my first shot at solving the problem was to subclass and override the relevant factory methods with behaviour that looks into the cache before invoking the superclasses create method. This worked fine, however I realized I needed an object cache for more than one factory in that particular app and subclassing all of them would have been a tedious excersize and also would have meant to configure the CachingFactory instances using IOC where the standard factories were in place now.

This is when I remembered a dynamic proxy example I had played with a while ago. The basic suggestion was to use interfaces and add behaviour before and after invocation. Exactly what I needed.

I converted the code sample to intercept all my create methods and manage the cache while doing so. The create methods parameter[] served to create a unique identifier for any given object and voila - I was done. The caching proxy now intercepts all my factories and is simply wrapped around any original factory object.

After this excersize I'm left with the feeling where something was so simple and beautiful that you wonder why you haven't always done it this way?

Presented at SJUG yesterday

2004-08-27T11:08:00.000+10:00

Well yesterday I finally got to present at SJUG. We had only 6 people, maybe because we shifted to a Thursday, however I thought the presentation was well received and people got interested in java imaging.

We had a small discussion afterwards on how to attract more people to present at or simply attend Sydney JUG and Dion suggested reviving some of the good old things such as the "who has the best IDE" war :) I had to cringe, but admittedly he's right. Polarization just never fails to attract audiences.

Who knows, maybe we should really try an IDEA vs. Eclipse shootout and see how many people turn up for that!