Stupid Development Tools

At Autodesk, basically the source control and bug tracking tools suck. We use VSS for source control, which is primitive compared to even CVS (supposedly developed in the 1980s). For bug tracking, we use "Clarify", which has a Win32 interface that is clunky even for a Windows 95-era program. The web interface is not much better, it's buggy and only seems to work on IE. It also is quite slow, given that the company is so large, and has been around for so long, there's about 1000 different products and build numbers to wade through, along with 1000 plus developer names, etc. Since I only work with 1 or 2 of those, and 2-3 developers, I don't see the point of presenting me with all that confusion. To top it off, they are both very, very ugly. The icons for both are primitive 16-bit pixel do-dads.

Working with VSS and Clarify makes me pine for the days of CVS and Bugzilla. Sure, those tools were never that great, but they were never excruciatingly painful. Other painful tools in my life have been Clear Case. (Clear Case is famous for requiring a full time staff member just to administer the tool since it's so complicated and convoluted.)

Autodesk, being the largest company thus far I've been at, seems to use the worst development tools. Likewise, in the same backwards fashion, expense reports and invoicing is processed via paper and manual data entry. I enter my expenses in an Excel spreadsheet, print them out, and then somebody manually copies my figures into some other system.

Anyway, today's discussion brings me to this: I got sent some e-mails from a fellow developer at work for not including enough detail in a "subdoc" submission. I protested that the bug number should be sufficient, alas not.

What is a subdoc?

At most companies, when you do a source code submission, you simply comment the submit with the bug number and who reviewed it. Simple right? And if your source control tool is integrated with the bug tracking software, you can see what files changed and what was changed.

However, since the development tools suck, the correspondence between code changes and bug numbers must be entered again by a developer. This subdoc must also be checked into source control and e-mailed out, since the tools themselves can't bookkeep for us.

So, to make a bug fix (trivial or not) here is the procedure:

  1. Change the code
  2. Show the code to a fellow developer for review. Usually this is done by generating diffs. But since VSS does not (through its crap UI) provide such a facility, I eventually wrote my own shell script. Though despite my script, the diffs I can generate aren't great since the best VSS can provide is diffs in the old UNIX format. The old format provides no context, making complicated changes impossible to review. Most developers visit each other's office to do code reviews.
  3. Figure out the next build number. These do not correspond to product release versions. Coordinate with fellow developers on which build number to use, as a pending build might preempt your check-in. (Note: At my last company and the ones before it, the build number is tracked by release engineering, and I did not know or care about them.)
  4. Create the subdoc. Note: Since the subdoc tool is a Win32 program, when new product versions come out, every developer must update his or her copy periodically. Copy the bug number in there. Copy the list of files you're going to commit. (4 and 5 may be done in reverse order … I may be violating the procedure.) Write a nifty paragraph of what you did, usually paraphrased from the logs in bug tracking. Hit the save button. Move the file from its random spot to the proper project directory.
  5. Commit. I usually log the commit with the bug number, but nobody cares in the VSS world what goes in VSS history.
  6. Add the subdoc to VSS.
  7. E-mail the subdoc. Send to the proper distribution address. (The tool can't seem to figure this out.) Copy the details of the bug in the subdoc.
  8. Comment in the bug, update the bug.
  9. Put the subdoc in the bug (since QA likes it there).

Here would be my preferred procedure:

  1. Change the code, write a test to verify the fix (or better to write the test, change the code).
  2. Commit the changes with the bug number. Changes made are automatically e-mailed to the team for other people to review.
  3. Update the bug with what was changed, change to fixed.

Note on 2. If no test accompanied the change, or the change was bad, then the developer gets in trouble. Bug gets reopened, letter gets sent to parents, etc. If the change was okay but crappily done, since it's only 3 steps to clean up the mess (reopen bug, commit with apology, close bug), crappy code is fixed more easily.

Release notes can be built from the list of bugs that was fixed for a release.

I hope I don't seem like I'm exaggerating. Ironically, there is a lot of complaining and concern about how far the team is drifting from following procedures and best development practices. Given the shit for tools we have, I am not surprised the team would want to skip a few steps of the 9 step process to fix a single bug.

Enough complaining about work for now…

Read and post comments | Send to a friend

Advertisements

About eliasross

Blogging before the word "blog" was invented.
This entry was posted in Uncategorized and tagged , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s