Career flashback: A Huge WTF and Making Things Better

Yesterday’s post reminded me of a company I worked for back in 2005. I was there less than a year, but I remember thinking at the time that I could have kept The Daily WTF (founded in 2004) busy for a long time based on the silliness I experienced.

Ten Years In

In 2005, I was ten years into my career. I had worked consistently since landing my first job in 1995, and in 2001 I ended up working as an independent consultant / contractor / developer. In 2002, only a year or so into what became 14 years of independence, my wife and I decided to move back to our hometown. We were starting a family (our daughter was born in 2001) and figured it didn’t matter where I lived since all my clients were remote. We also thought living close to our families would be good. We built a house and moved in shortly before our son was born in 2003.

The town has a population right around ten thousand people. The largest employer at the time was a prison. I think the current largest employer is the WalMart distribution center or it might be that other place…as it’s known in polite terms, the “pork processing plant”. You can get from one side of the town to the other in about 10 minutes, but if you want to shop at a Target or a mall or eat somewhere that ISN’T the normal fast food fare, Applebees or Bob Evans, it means driving at least 45 minutes.

By 2005, I wasn’t sure independent life was for me; keeping my client pipeline full was tough and work was drying up. Living in a small town limited my options, but one day I happened to browse the Help Wanted section of the local newspaper. I’m not sure what I expected to find since the town wasn’t known for technology, but a new listing jumped out at me!

A short break from independence

While I don’t remember the details of the job ad, it was for software development. I sent in my resume and a cover letter, and long story short, I landed a job that was only a five-minute drive from my house! The relief I felt at not having to deal with pipelines, clients, and invoices was immense.

The development team consistened of the CIO, who actively wrote code, and two other developers, both remote. There were several other people in IT, but they weren’t developers. The project was a Visual Basic 6 application that consisted of many components and was the bread-and-butter of the company. It’s what they used to do business. I was brought in to help move to the still young .NET.

What follows is from a post I wrote on March 5, 2008, a couple years after leaving, detailing some of the silliness as well as the things I did to try to improve the situation. The only changes I made were in formatting from HTML to Markdown so the post was easier to edit. Names were changed.

How I helped make things better: bringing order to a chaotic environment

Shortly after my training was complete, I went to my bosses office (Jon) to ask about getting started. After some hand-waving and scribbles on the whiteboard to show me how extremely complex the application was (typical of most meetings with this guy), he told me to get with one of the other devs (Mary) for instructions on grabbing the source code. Cool.

I gave Mary a call and said something to the effect of, “Jon said you could help me grab the latest source so I can start digging in.” Silly me. I was expecting something simple like “point your VSS here and get latest”, but noooo….that was not to be. ;-) Instead, I was told to connect to the “enterprise” server (which was actually a ratty-ass old desktop that was on its last legs, but that’s another story), copy all the sub-folders from “enterprise” to my workstation and open the project I needed. Keep in mind, this was a VB6 application that consisted of 50+ projects (mostly COM objects ala Windows DNA). Anyway, by this time, my head was about to explode when I said, “what? you guys aren’t using any source code control?”

Here’s where it gets bad…her response? “Source code control? What’s that?”

sigh

I asked her what happened when two developers needed to be in the same project at the same time. Notice I didn’t say “file”, I said “project”. She replied with, “oh, we don’t do that.”

I have always used some kind of source code control, so I was completely blown away by this. As crazy as it sounds, I actually had a tough time sleeping for a couple days after that.

Ouch. Ok. What’s next?

Not too long after that experience, I was given my first real assignment — figure out why a report wasn’t working correctly. I don’t remember the specifics, but at the time, I was chomping at the bit to get some real work done, so I said “no problem!”

I “got latest” — yea, I copied code from the so-called server to my dev machine and started digging into this particular issue. In order to gain better understanding of this issue specifically and the overall system in general, I checked to see where the report was getting its data. I figured once I knew what stored proc the report was using, I’d be able to dive into the database, run some queries and figure out why the report wasn’t working.

Ok. Easy enough, right?

Boss: How’s it going with that report?

Me: Fine. Uhh, I want to run some test queries. Where is the test database, or better yet, the development DB?

Boss: Yea. We don’t have those. You’ll have to use the production database.

Me:

Me:

Me:

Me: Ummmm, ok. I’ll let you know how it goes.

So, within my first two weeks, I discovered they didn’t use SCC and they had no real development environment. Not cool.

Note: At this point, I’m sure there are some readers saying, “dumbass…didn’t you ask questions during the interview?” Yea, I did, but honestly…in 2005, who the hell wouldn’t be using source code control or understand the importance of having a development / test database? Geesh, give me a break. ;-)

Making things better

I pushed on and fixed the report issue, making sure to do a diff before “checking my code in” (lol, that sounds so stupid when all I was doing was copying my files back to the server). At my status meeting that day, I asked why they didn’t have dev or test databases to work on? In fact, I went so far as to ask about the lack of SCC too. Oh, did I mention they had no issue tracking system in place either?

While I can understand his answer, “we’re all too busy”, I had a hard time accepting it. I mean, c’mon, I know everyone was busy, but how tough it is to setup SCC (even it it was just VSS)? How tough is it to grab a SQL backup and restore it somewhere else?

As it turns out, the SQL backup was an issue since the production database weighed in at around 80GB, but I knew I could come up with something. ;-) From that point on until the day I left, I made it my mission to improve things as best I could.

Source Code Control

It actually took a lot of convincing to get my boss and the other devs to see the value in source code control, but I kept pushing (gently, of course). Finally, my boss relented and told me to provide a recommendation. I knew I didn’t want to use VSS, and at that point, I wasn’t familiar enough with CVS or SVN, so I picked SourceGear Vault. I liked Vault because it uses SQL Server as its back-end instead of being file-based like VSS.

The easiest part of the whole process was importing all the existing code — that took about 20 minutes. The hardest part was convincing the team how important source code control was and explaining all the benefits. My boss was an easy sell, but a couple of the other team members took more convincing. I provided everyone with ample notice of when the file share would be closed. Over the course of a few weeks, I provided everyone with a written tutorial for using Vault as well as providing them with in-person training. It was a huge mindset change for them, but eventually everyone bought into it and started using it. Since everyone was so new to the concept of scc, I wrote a small app that emailed everyone a list of their checked out files each morning. :-)

Issue Tracking

Along with Vault, I also convinced my boss to invest in SourceGear Dragnet for issue tracking. The only issue tracking they had in place when I got there was the IT Help Desk web site and notes my boss took during meetings. Neither was acceptable in my opinion because a) the developers almost never looked at the help desk web site and b) notes always got lost. Dragnet allowed us (the devs) to have full control over our issue list. I wrote a small app I scheduled to run every morning which emailed all the devs their open issues. This really helped!

A Dev/Test Environment

Getting everyone to use source code control was a huge victory, but it wasn’t enough. I had to get them away from their old practices of using the production database to test against. One of the first things I did was grab a SQL backup (yea, all 80gigs) and began trimming away all the fat I could. Since it was also used for testing, there was a “metric buttload” of temp tables I was able to drop. I also trimmed some of the larger tables down to a few hundred rows instead of millions. In the end, I was able to get my copy down to a reasonable 20GB. I also scripted the entire database and checked the scripts into Vault.

Once I had the database trimmed down, I had to figure out where to host it so the other devs could use it. My first thought was to use one of the existing servers, but decided to go the virtual route instead. I ended up building several virtual machines (using Microsoft Virtual PC / Virtual Server) including:

• build
• webdev
• webtest
• sqldev
• sqltest

I also built a couple VMs for client testing.

By the time I left, I had taken them from no development environment to a full-blown virtual environment that included development, testing and staging servers. I had made it possible to fit a copy of the database on a laptop, brought in a great issue tracking system and most importantly of all, gotten them to use source code control.

You know what’s crazy about the whole thing? While I was brought in to help move them to .NET, when I left they were still actively developing in VB6. I personally worked on several projects while I was there that used .NET, but my boss never let me work on moving the main application to .NET. I heard they finally did move to .NET, but it was at least 6-8 months after I left before that happened — and they ended up outsourcing/offshoring most of that work. :-\

this is where the old blog post ended

Back to 2024 and some reflections

That was a fun flashback to a much different time. I made assumptions about the practices used back then, and I make the same assumptions today. Thankfully it’s much more likely that people are using something something to manage their source code. It’s just as likely that they’re using something to track tasks and issues, although it’s been a long time since I’ve seen anyone use a traditional bug tracker. I’m grateful for how easy it to use to virtualize / containerize things these days, too.

It was an interesting gig, and I learned a lot. I also made a lot of friends, but in the end, the pull of independence was too strong to keep me around. I left after about nine months.

Change where you work, or change where you work

Thinking back to yesterday’s post where I talked about problem solving, the story I told today reflected those three steps; I understood and explained the problem, I came up with solutions along with pros and cons, and then I suggested a course of action and why it was the best.

Chaotic environments can be stressful, and bad leadership can make things more difficult, but it IS possible to improve things. I didn’t sit back and bitch; I came up with a plan, used influence to get others to see the value in what I was pitching, collaborated with others to make it happen, and eventually left things better than I found them.

---