When I was a kid in the early 80′s, “home computers” were becoming more popular and I was chomping at the bit to own one of these incredible machines. I begged my parents for one and my persistence was finally rewarded with a TRS-80 Color Computer. But one computer wasn’t enough. I had to play with every computer I could get my hands on. I’ve used and/or written code on every Tandy machine made since the most awesome Model 3′s; Vic-20, Commodore 64, TI-99/4A, Atari 400 & 800XL, Amiga 500 & 1000, Timex Sinclair, Apple II, IIe and IIc.

Not long after getting my first computer, I learned that I could connect with computers around the world through this neat little device that people were calling a “modem”. I had to have one of those too and my parents finally relented. After hogging the household phone line and nearly deafening my siblings with the modem’s screeching sounds, my parents gave in and bought me my own phone line. I was now free to explore the world through my computer.

- I ran a BBS. With a 300 baud modem. I recall how awesome it was to upgrade it with my sweet JCAT 1200 baud modem.

- I  wrote my own BBS software that at least a few other sites in Dallas used.

- I recall how important “Hayes compatible” was. I took pride in knowing the entire AT Command set.

- I remember XModem, YModem and ZModem protocols. I wrote my first XModem implementation in 6809 Assember.

- I had a subscription to CompuServe. Or Compu$erve as everyone referred to it.

- I remember when FidoNet was the coolest thing around.

- I remember writing war dialers.

- I remember phreaking. I also remember that when the Computer Crime and Abuse Act was passed in 1986 it scared me enough to stop my practice of using software I wrote to find and steal MCI long distance codes to fund my  long distance BBS habit.

The early-mid 80′s were a great time to be a kid with a computer. Most of society still looked at these funny machines with skepticism, but we started to see our weird culture start going mainstream. Magazines, TV shows and even movies began to focus on our little world.

- I remember typing in programs that were published in magazines like Byte and K Power.

- I never missed an episode of “Whiz Kids”. I wanted my computer to talk to me the way RALF talked to Ritchie.

- I still remember where I was when I saw the commercial for the movie War Games. I begged my mom to take me until she did.

- I remember seeing the Apple 1984 Superbowl commercial live and thinking “Whoa! I gotta play on that!”

- I remember going to the mall and seeing Dillards (of all places) selling the first generation Macintosh. The employees would shoo me away when I would plant myself in front of it for hours.

- I owned a light pen and remember thinking how cool it was.

- I remember using an IBM PC Jr and that awful, awful keyboard.

Like any kid at the time, I was into video games. I learned how to control the rudimentary graphics on my various computers to write some really awful games. But nothing compared to some of the cool games available back then.

- I spent hours playing Bard’s Tale on a C-64.

- I played text-only adventure games from Infocom such as Zork and Planetfall.

- I wrote my own adventure games in BASIC. It saved your progress to cassette. High tech stuff.

Not surprisingly, my early 20′s found me making a living as a developer. No fancy GUIs back then. The mainframe still ruled and MS-DOS was the lingua franca of the PC world. My first job gave me the opportunity to work with everything from ancient systems to new fangled operating systems like Windows and OS/2.

- I wrote code to run on IBM 360, AS/400, VAX/VMS, Unisys A-Series and even toyed with a UNIVAC 2200.

- I was paid to write production code in Assembler, Algol, Cobol, C & C++, every flavor of Visual Basic including VB DOS, Access, dBase, FoxPro, Clipper, GW-Basic& QBasic

- I wrote TSR programs in Assembler for DOS.

- I wrote printer device drivers for some of the first version of Windows and OS/2.

- I worked on mainframes that still used 3340 Winchester drives.

- I used 8 inch floppy disks. In the 90′s.

- MASM 6.0 was my tool of choice for many years.

- I remember having to be concerned with extended and expanded memory under DOS.

- I learned entirely too much about Netware and worked towards gaining my CNE.

As Windows gained adoption, I took it upon myself to learn this new OS from the inside out.

- I bought several books on the Windows API and taught myself how to write a Windows app in C with just the API.

- I remember getting the HUGE box that contained Borland C++ 4.0.  I learned OWL and Turbovision.

- MFC came along and I began a long, sad journey of using MS development tools.

- I wrote VBXs and OCXs using Visual C++.

- For kicks and giggles, I wrote a fully functioning Windows app in Assembler just to prove I could do it. It was the last major Assembler code I’ve written.

After spending years working with Microsoft technologies, time has moved on and today finds me writing Ruby on my Mac and re-discovering Linux which has re-kindled much of the hacker mentality I had when I was a kid pushing buttons to see what it would do. I’ve seen a lot and I’ve learned a lot over the years. I’ve seen countless technologies and fads come, and I’ve seen ‘em go just as fast. But one thing that has never changed is the excitement I still get when I figure out something new; when I get the computer to do what I want to do. 30 years later, it’s still the same feeling.

There are some challenges in having a distributed team, but we’ve found the following tools to be indispensable:

GitHub – A distributed version control system is a must for distributed teams and I know of no better tool than GitHub. Although we are moving to Rails, we have quite a bit of legacy C# code and we’ve had the incredible misfortune of using Microsoft’s TFS in the past. Only SourceSafe would eclipse TFS in terms of pain and suffering in it’s daily use, so GitHub has been a breath of fresh air for us. Beyond the fact it is ridiculously cheap for us to host private repos, it is fast, doesn’t get in our way and has great tools that let us view source, make comments, view commit history, manage our branches, etc.

Pivotal Tracker – If you aren’t already using Pivotal Tracker, you owe it to yourself to check it out. It’s a “Free, lightweight Agile project management & team collaboration” tool from Pivotal Labs. We can quickly and easily manage all of our stories in a single interface. It’s power is in it’s simplicity. We’ve tried many Agile tools such as Version One and Mingle (and paid tidy sums for them), but Pivotal Tracker is by far the best even without considering it’s free. I’d gladly pay for it. It’s that good.

Campfire – Distributed teams still need a way to communicate and email and instant messenger aren’t always the best platforms for that. With Campfire, we have a private chat-room for our devs where we can easily communicate back and forth, post links, the occasional screenshot and the usual daily dose of pointless banter and jokes which is always healthy for a team. All of the discussions are archived and searchable so it’s easy to go back and find information that has been posted in the past. I’ve been surprised at how useful Campfire has become for us. There are a number of great Campfire clients out there, but the best one that I recommend is Propane. (Although it is Mac only)

These tools would be great in and of themselves, but the fact that they are all integrated is even more powerful. Whenever a commit is pushed to GitHub, the commit notes are pushed into Campfire for everyone to see. Whenever someone adds or updates a story in Pivotal Tracker, everyone sees that in Campfire. There is no need for status updates, time tracking or other management nonsense. It’s clear what everyone is working on.

What tools do you use for your distributed teams?

How many of you already know how this is going to end? Well, for those they don’t already know, it didn’t end well. The code behaved nothing like what the comments said.  Over the years, the code had changed. But the comments had not. So I ended up wasting time trying to unlearn my preconceived notions about how the code worked. 

Our lead developer, Sean Scally, is not a proponent of comments and has been on a mission for years to curb the practice of “undocumentation”. He feels that the code itself should be clear enough for the developer to understand what the code is doing. If it isn’t clear, then refactor it until it is.  After we got turned the wrong way because of my out of date comments, he smugly joked about my “comment perjury”. But he was right. My comments were lying to us.  They were well intentioned when they were written, but most developers, myself included, rarely go back and update the code comments.  

So now, every time I feel the urge to drop some comments to explain what the code is doing, I take a look to see what I can do to make the code a bit clearer.  One of the best things I’ve found is to use the Extract Method to pull a code fragment into its own method, where the name readily explains what the code fragment is doing.  Unit tests are another way to document your code without comments. In our business, the business rules can be fairly complex and change frequently. Trying to write comments that explain this logic is fraught with peril. (As I’ve learned) It’s much safer to have unit tests that readily demonstrate what the business rules are. As the rules change, you update your tests then update your code. No need to remember to update that big block of comments that nobody bothered to read anyway. And you get the added benefit of having your code under test coverage.

As in all things in life, moderation is key. I still hold that a properly placed comment can make a world of difference in understanding the code. But they should be used carefully and judiciously and only after other ways of documenting the code have been exhausted.

 - “Test Driven Development is a huge scam”

 - TDD “vastly increases the amount of time to program anything without any benefit.” 

 - Having developers produce unit tests that cover “even 50% of their code is ridiculous and wasteful.” 

 - Asking developers to provide large amounts of test coverage is “like asking the fox to watch the hen house”

 - Unit tests should be “written by professional QA Engineers”

My first reaction to TDD was “More ivory tower academia from people who spend more time thinking about software than actually writing it” and I dismissed it. But I kept hearing about it and noticed that people that I respected were discussing it a lot more. I finally took a deeper look into it and though confused at first, I began to see the benefits. After a few TDD sessions, I became a believer when I saw the quality of the code that was produced. Today, I still consider myself a TDD newb, but I definitely understand the value.

The reason that I see the value is that it solves a business problem for me. I’m not some techno wunderkind who salivates over the latest flavor of the month. I love developing software, but I’m pragmatic: I want to make money. (See: Capitalism) I take a serious look at anything that can help us produce better, more maintainable software faster. Although our software has always been pretty stable, we had plenty of incidents where having decent tests would have saved my bacon. I quickly found that writing unit tests on existing code was often tricky because the code itself was inherently un-testable. This was a problem. I couldn’t easily write automated tests so my choices were lengthy manual test procedures or just rolling the dice and hoping the code didn’t break.

So for me, TDD was a step towards solving that problem.  Today, our new development reaps the benefit of TDD and I’m quite happy with the result. It works for me. YMMV. If TDD isn’t working for you, what type of testing is?

I’ve been wanting to implement CruiseControl for years now. But there was always something else to be done so it go pushed to the back burner. Bad idea. I wished I had implemented this when we started. Beyond it’s stated purpose of making sure everything will build, implementing CC.NET provides other benefits. For example, one project that I added had about a hundred unit tests, but several of these tests were failing. And nobody knew. Everyone ran their individual tests during development but nobody was running all of the tests. Granted, that shouldn’t have been allowed to happen. But now with CC.NET, those tests are all run automatically upon a check-in. And now everyone sees that the tests are failing. No need to depend on a human process to check the tests.

Another benefit of installing CC.NET was to make us think of a better way of handling our project directory structures. A few months ago in preparation for getting CC.NET installed, Sean Scally took some time to research various ways of improving our directory and source control structure. He came across TreeSurgeon and we’ve been very pleased with it. If you haven’t looked at TreeSurgeon yet, I highly recommend it. It’s a great tool that will create a project directory structure, a solution that contains your domain DLL, NUnit test project and a NAnt build script. Best of all, you can download the source and change it to your heart’s content.

What type of things are you doing in your shop to make incremental improvements? I’d like to hear about your experiences!

Thursday morning I was demo’ing some portions of the app to our Support staff when the application became unresponsive. Within a minute, it was clear that IIS was no longer responding. Ack! A quick look at the server showed that the IIS worker process had in fact died. A quick, but very inconvenient, IISReset command and everything was working again.

I meant to look into the cause of the crash, but got busy doing other things. Then, later in the day it happened again. At this point, it was clear that something with our rollout was causing a problem because IIS had never experienced crashes like this before. Our lead developer looked into it and found that IIS was slowly leaking memory and eventually crashed when it ran out.

A few Google searches later and we found the source of our problem: Our use of the NHibernate session factory. What we were doing was creating a new session factory each time we needed a session. As we quickly learned, this is very much frowned upon and will cause memory to disappear faster than your shares of WaMu stock. 

The solution was simple: Wrap the session factory in a singleton and keep that sucker around. Lesson learned!

What we’re looking for is a developer who takes pride in their work, is dedicated to learning and improving themself and can work well on a team. Some of the things that we value are test driven development, pair programming when necessary, domain driven design and building solid, testable code in a reproduceable way. No death marches, no mandatory overtime, no insane schedules.

If you also value these things and have a solid background in C# and ASP.NET and are in the Dallas area, then we’d love to hear from you. I can be reached at hoffman@autorevo.com

However, yesterday was one of those days were everything just clicked. Two of our developers started off in the dev conference room outlining some initial class designs and thinking through some initial code. They hit a few sticking points and asked me to come in for another opinion. We talked about their initial design for a bit and I suggested that they had enough of a design to start writing some tests. There was the usual “what about this?” and “we don’t know how this will work yet” comments, but there was agreement that they were getting diminishing returns on talking about it and it was time to write some code.

So after lunch they paired up and wrote their first test. The code they wrote to pass the test was done in the most basic and simplest way possible. They then refactored. And wrote more tests.  And refactored some more. By the end of the day, I checked in with them and they showed me some pretty impressive code that had a solid design and great test coverage.

The code that was written was cleaner and more elegant than the code that any of us had originally discussed during our brief design meeting. In our design meeting, we had thought of doing it one way but the final version was completely different. And better. That’s one of the huge advantages of TDD: We let the tests drive us to a better design. Rather than trying to force fit our preconceived notions into the design, we allow the tests to become the basis of the design. Many people a lot smarter than me have written extensively on this topic, so I won’t bother to repeat it all here. But suffice to say, TDD is something worth exploring if you want to improve the quality and testability of your code.

Pairing also paid dividends. Both of the developers agreed that the code that was written was better than what either of them would have written independently. It’s an example of the whole being greater than the sum. 

I know now. Largely due to the fact that my ignorance of packaging in the early days of AutoRevo caused a lot of headaches for us down the road. In the beginning, it was easy. Our software was simple and didn’t do too much. We had a web application in one assembly and we had our business objects in another assembly. The business objects, which I cleverly named AutoRevo Business Objects or ABO, contained classes for things like Account, Inventory and some stuff for dealing with eBay.

Even my less astute readers will already see the problem. But I didn’t. Even on that poor foundation, I kept adding stuff to ABO. Much like building a city next to a massive river, an ocean and a large lake, something really, really bad is bound to happen someday. Before long, ABO contained virtually all of our business logic for dealing with accounts, inventory, authentication. dealer websites and a bunch of other things. It also knew everything about launching and revising listings to eBay. It was all knowing and all powerful. A good thing for a deity, but not so much for a single software component.

Unit testing was something that we only paid lip service to at the time and the tests that we did have weren’t very good so the predictable result is that anytime we had to roll ABO, we risked breaking, well, the entire application. And we were forced to roll out the entire AutoRevo Business Objects DLL no matter how simple the change was since it contained everything. eBay changed a rule about revising an auction? Roll out ABO. Wanted to change a minor setting regarding an account? Roll out ABO. My original design decisions were bearing fruit and it wasn’t too tasty.

I wished I could say that all of this was behind us now and that all of our code is a shining example of proper dependency management. But it’s not. We’re still working to break up those dependencies. We’ve gotten a lot smarter and do things a lot differently today, but legacy code is something that always has to be dealt with.

So this week I’m going to be writing about some things that I’ve learned along the way, some metrics that are useful for gauging the health of your packaging and discuss a really cool tool that can be used to help you understand your software dependencies. Hopefully, you can be spared some of the same mistakes that I made.

We recently purchased Version One’s Agile Enterprise. It’s a great piece of software and we love it. I’ll have more to say on it later, but overall, it is working quite well for us. However, one annoyance is their lack of default configurations for each user.

Case in point: Their software has a nice feature so that a little mail icon appears on the screen when a user receives a message or alert.

Version One Notifications

Cool. “That’ll come in handy”, I thought to myself.  While we’re working on a story, we’ll frequently need clarification from our Product Manager. So we add a task to the story and assign it over to him. My clever plan was that we just assign the task and he would see the notification thingy so that we wouldn’t have to bug him for an answer. Developers could move on for the time being and the Product Manager could work un-interrupted until he has the time to get to the task. Efficiency is at hand!

Except it didn’t work that way. The developers dutifully created the tasks, but after a while it became clear that our Product Manager wasn’t seeing the notification. After a bit of digging, we figured out that each user has to subscribe to the notifications that they want to receive. So if you want to know that someone has assigned you a task, then you have to create the appropriate subscription. Bah!

Their subscription / notification system is pretty slick and very configurable. But if fails in one simple aspect: It makes me think about it before I can effectively use the software. I just expect that when a task is assigned to me that I would receive a notification. I would expect that to be the default behavior. I do not expect that I will have to go figure out that I have to create some subscription thing for it.

Frequently developers get overly excited about how configurable and customizable their creations are. They brag about the endless configurations and options. How a user can make it do whatever they want.  But they forget that most users really don’t care and just want the product to work out of the box without having to think too hard about it.