22 August 2006

Transitions II - Back from the Dark Side

I mentioned in Transitions that I'm starting with Industrial Logic in, well, a week! As part of my new job, I'll need a new laptop. I was given the choice of an IBM tablet, and IBM ThinkPad and a MacBook Pro.

Waaaaaay back in mid to late 80's and into 1990, I used a Mac alongside 3270 terminals and UNIX workstations. The Mac was for the managers, so that they could do their spreadsheets, etc. in something more user-friendly than the mainframe spreadsheet application. It also meant the they could print immediately, rather than having to wait up to 2 hours for a print job. I wrote a couple of support applications on the Mac, and just loved it! I guess I was predisposed to liking Apple since my first experiences with computers were on a 48K Apple ][, and my first machine was a 64K Apple ][ clone.

So, I was quite excited at the chance of actually using a Mac once again. I did have some trepidation, though, about whether I would have a significant learning curve after 16 years on the Dark Side, and wasn't sure if I would be able to use the same tools I do now. I consulted J.B. Rainsberger, Dave Astels and my good friend Jim Leask, all of whom are currently using Macs (although Jim isn't using one yet for real work). They assured me that not only are most if not all of the current tools are available in OS-X versions, but in many cases there are even better tools. Plus, with utilities such as BootCamp, Parallels or simply vmWare, I could still have that cheap Mac clone OS available if I needed it. ;)

So, according to Fedex, my shiny new MacBook Pro was shipped from Shanghai this morning... well, their morning, which would actually be yesterday here... or something like that. Regardless, Transition II will begin shortly. I can't wait!!

14 August 2006

Transitions

A number of months back a posting on the XP Job list caught my eye. It was for an Agile Coach position with one of the companies at the tip of the agile spear, so to speak.

Despite the fact that I have been an independent consultant for over 12 years now, I thought that it was an interesting enough opportunity that I should look into it. So, off went my resume. I heard back from them after a day or two, and we did some interviews over the phone. Next thing I know, I'm on a plane to the Bay Area with a Led Zeppelin song in my head (that would be Goin' to California for the younger readers! ;) ).

After my first real interview since about 1990 or 1991, I was set for a bit of contract work over the summer. During that work, I was officially offered an Agile Coach position, and I accepted it.

So I'm quite pleased to announce that, beginning in September, I will be an employee of Industrial Logic!

It's with mixed emotions that I'll be closing up the store, if you will, for Mayford Technologies. I started the company shortly after I had heard about Extreme Programming, and have ridden the highs and lows of the agile adoption curve here in Ottawa. I have tried (and I hope succeeded) to get Agile on the map here, and will certainly still be involved in the local Agile community.

It has been a good run for the past 6 years with Mayford, but it's time to move on to bigger and better things and this position with Industrial Logic is certainly that.

Many thanks to all who have helped me to get to this point - you're too numerous to mention - and I'm really looking forward to being the local presence for a great company with great products and Agile training services.

4 August 2006

Professionalism

My disgust at the quality of the code on a project I joined in March came to a head a few weeks back. I remember when I started, looking at some really crappy code. I thought, "Wow - this is a real opportunity to do some good, cleaning up this mess!" I didn't realize that after 18 years in this business I could still be naive!

I had heard the almost apologetic comments from some people on other projects who had been around for a while... the original developers were hired right out of school, and their designer didn't pay much attention to them because that person was involved in a few projects, etc., etc. However, what gradually bothered me to the point of blowing was that not only did the original developers have nary a clue about O-O development, but later, more experienced people just exacerbated the problem.

I can't remember ever seeing code as tangled as this is. I would like to use the term Big Ball of Mud to describe the code, but that would be unfair to mud. Coupling doesn't begin to describe it either, and code reuse was strictly through copy and paste (there was a lot of "code reuse"!). A transaction from a business perspective could consist of several different interactions with the database, each of which using it's own Connection, and some with autoCommit set to true! This created many situations in which data was left in an inconsistent state that was, at times, impossible to fix.

In one case, we detected a logic error in some code that determined if a database insert or update should occur. I fixed that error and suddenly 3 more cropped up. Other code had been written that assumed the error was there!! AAAAAAAAGGGGGGGHHHHHH!!! My early naivete was quickly overcome by the pressing need to just keep the system afloat so that the Customer could do their job. As a result, many relatively straightforward but "deep" refactorings kept being pushed back owing to more pressing work.

The data access was all pure JDBC, with no abstractions to simplify the code. I found several instances where PreparedStatements and ResultSets were being created and accessed within loops, but only closed outside the loop. I'm not a really deep bit-twiddler, but that just stinks to high heaven of a memory leak! On top of that, the DAO's consisted entirely of static methods, meaning I couldn't just pull out an interface and use a mock for testing.

Two weeks ago, another developer joined the team. He had been working on another project at this client and sat close by, so I knew him a bit and knew that he seemed like a decent developer. After he saw the code for the first time, he said he was kind of excited because it looked like a real opportunity to do some refactoring. The first thing he was going to do was change the DAO's to no longer use static methods, extract an interface and start using mocks to allow testing. :) Two weeks later, he now understands my frustration!

My real frustration, though, is that people were paid to produce this shit. I'm sorry for the expletive, but that's what it is. I even sent off the link to Uncle Bob's We Will Not Ship Shit article on Artima to the rest of the team. The people who worked on this system were supposed to be professionals. However, they didn't have a bloody clue about the principles of object oriented development. OK, so the original developers were young and inexperienced. I guess they skipped a few too many classes during the OO lectures, or whatever school they attended didn't venture much further beyond Hello World in the labs. However, those developers were replaced with experienced people. Those people should have known better. When I see work such as this system, even I start to believe that the software development aspect of the IT industry needs some sort of accreditation system that requires an apprenticeship period in addition to education.

After about a month on the project, I sat down for a chat with the team's manager. I talked about the state of the code, and how in terms of technical debt this was way beyond the Hired Goons stage. There was a full-fledged hit out for this piece of crap. He asked what I thought about re-writing the application, and I immediately agreed that it was about the only way to make progress. Fortunately, that's about to begin in the next few weeks. Unfortunately, I'm leaving that contract at the end of August. Maybe the other developers will be more productive after I leave because they won't have to listen to my incredulous remarks from my cubicle, "Oh my... what the... what the hell were they thinking?!!" I'd like to put a smiley beside that last sentence, but I do that almost every day.

Ironically, in the Customer's eyes the members of the development team are gods! They've been dealing with a dysfunctional system for so long that any improvement is seen as a breakthrough. I can just see it now... once the properly rewritten system is in place and has few if any production defects, the developers will be mere mortals again and will be in the dog house if even a single bug is found!! Remember, you heard it here first. :)