Archive for March, 2006

Instructions? We do’n need no steenkin instructions.

Posted in Daily Entries on March 27th, 2006 by Mike Taber – Be the first to comment

Today I had a very unique experience. I was at a client site working to debug this multi-threaded test application they had written, when the HR director stopped by with a set of instructions for the phone. They had apparently changed all of the voicemail systems, so wanted to make sure everyone knew how to use the new voicemail.

I find it ironic that the one and only time that I’ve ever received written instructions on how to use the phone in my office, it also happened to be the one and only place I’ve never received a phone call. When I’m not there and my clients need to get in touch with me, they call the Moon River Software hotline.

When I am on site, and the developers at the client site need to get in touch with me, they send an email, or pop into my office. I had actually stumbled upon the idea for this blog post nearly two years ago. It’s not that a phone is a particularly complicated piece of equipment. Everyone knows how to use the standard features of a phone. Simply pick up the phone, make sure there’s a dial-tone, and dial the number you want.

I don’t generally exercise most of the advanced features very often though. Perhaps if I were in sales it would be a different story. But for those of you who write code and aren’t managers, how many times have you been at home and felt the need to forward the call to someone you live with by pressing buttons to send the call to another line? Usually it involves handing over the phone, and if you have teenagers, hoping that it eventually finds its way back to the charger.

In an office, you deal with clients, and cordless phones are far less common. Even if they were common, you usually have more than one line coming into the office, or at the very least each person has his or her own extension. I’ve never for the life of me been very good at talking to a client and then forwarding them to someone else, for this one very good reason.

I’ve never been given instructions on how to use my phone at the office for anything other than setting up voicemail. I distinctly remember one time I was given instructions on how to set up voicemail, but not how to access it or delete messages. And when you called, it didn’t walk you through it either. Voicemail security was a big issue, or so I was told.

If you’ve looked at some of the newer cell phones, they’ve gotten pretty bad too. I know Joel isn’t particularly fond of his cell phone and its on/off design. I understand his underlying point, but I don’t think he made it very well. Turning on and off a cell phone is something you probably do enough that after doing it once, you’d need to remember it. Had his initial complaint been about something other than a ’scary red button’, I could probably take it more seriously. Perhaps differentiating between the icons for office and cell phone numbers would have been a better argument.

But I do agree that there are certainly features of both my cell and office phones which are far less than obvious. *6x generally does something special. If I had a little notecard that I could keep next to my phone, I could tell you exactly what it was, but I never have until now and on a phone I rarely, if ever use no less.

So, I suppose that today’s post is just Mike being whiney about having never been given formal instructions on how to use a phone. Perhaps if it were important, I’d have tried harder to figure it out but it hasn’t been. I suppose I also have to acknowledge the possibility that I’m an idiot, but I can’t imagine I’m the only one who’s ever told a client “I’m going to try and transfer you, but if it doesn’t work, then Dave’s extension is x453. *click* bzzzzzzz….. oops.”

Share/Save/Bookmark

How to focus on quality

Posted in All Articles, Software Development on March 16th, 2006 by Mike Taber – Be the first to comment

Focus on Quality. It sounds innocent enough. Just make sure you do everything perfectly, or at least as perfectly as you are able.

If only it were as simple as that. I distinctly recall during my younger years as a developer, believing firmly that if software you wrote had bugs in it that you were aware of, you simply should continue working on it until it didn’t. This was about the time that Windows would crash on you every 20 minutes, plus or minus 30 minutes. It was increasingly frustrating to even use a computer, mainly because the system would just die, often for what was apparently no good reason.

“Why didn’t they fix this before it went out the door?!?!”

Well, either they didn’t know about it, or they didn’t care. The correct answer is neither. They simply didn’t have time.

As my career unfolded, I ran into an increasing number of managers who simply didn’t know what they were doing, and of course I knew better. “The software still has this bug in it. Why are we shipping without fixing this bug!”

Eight years later, I finally know the answer to that. If we waited until all of the bugs were fixed, the software would never be finished. There’s always something else to tweak, more functionality to add, a bit more performance that could be squeezed out of this algorithm or that one. Developers tend to be perfectionists. I think you almost have to be if you want to be a good developer. But it can be frustrating to know that your software that is going out the door still has problems, or isn’t as manageable as you’d like it to be.

The main source of these problems is really a lack of time to do the work. Adding more developers may solve short term problems, but it’s not a long term solution. It simply adds to the confusion generated when architecture changes are made, or more features are added. But there are some rather simple things that you can do to cut down on the time that you spend working on trivial stuff that you shouldn’t have to devote extra time for to begin with.

If you take steps to increase the amount of time available to you, then any time savings you create can be used to increase the quality of your product. Interestingly enough, many of these crucial time savings actions actually contribute to making a higher quality product.

1) Use source control for nearly everything, no matter how large or small your team is.

Even when working on projects all by myself, I always use source control of some kind. It’s incredibly stupid not to, but people still do it. These are the people who have never lost their work to a drive failure. Your hard drive can go at literally any time. Most of the time, you at least have a little bit of warning. With one exception, every drive failure I’ve ever had gave an audible indicator that something was going seriously wrong.

The drive would start clicking, or making strange whirring noises. That meant it was time to buy a new drive and copy everything to it ASAP. Some people use multiple computers and store copies on multiple machines. This is rather effective, but if you’re doing this, then you’re missing out on one of the key benefits of source control, which is the ability to go back to a previous version. Check in early, and check in often.

If you’re copying files all over the network, then you’re wasting disk space left and right. Disk space is cheap right? Certainly. And if it’s so cheap, then why not use a source control product that tracks the changes between versions for you? Then you can track every version you’ve ever checked in. Personally, I prefer to use SourceGear’s Vault. If you’re flying solo, then Vault is free for one user. Perforce is free for two users. And if that’s the price for you, then you always have CVS to turn to.

There are certainly other options, but source control is a must. Don’t say that I didn’t warn you.

2) Use a virgin build machine to build all of your test builds.

There will certainly be cases where you need to spin off a special build for QA to test something specific, but for your regular releases, you really need to build your product/application on a virgin build machine. ‘Virgin build machine?’ By that, I mean that your build machine should not install the product, nor should it ever. Developers sometimes install software that adds things to their Global Assemblies, or they assume that code or images they added to their local solutions have been added into source control. If the build breaks because they forgot to check something in, then it’s a sign that the process is working.

In my own environment, I have a Windows XP Professional machine that has all of the latest patches running builds. Better yet, my build machine is actually a VMWare image. So I can back it up and move it around whenever I feel like it. If a developer needs to make some tweaks to the build process, or needs some one shot customizations done, he can copy the image, tweak it, and never even touch the actual build machine. There’s no chance of hosing it. Better yet, is the fact that if anything ever happens to the computer it’s running on, you simply fire up the image on another computer. In 2 minutes, your build machine has been recreated. No hassle, no fuss.

“But, what’s the big idea of having a build machine in the first place? My computer can build the software just fine!”

Perhaps. But my build environment is a little more complicated than simply clicking Build. First, it gets all of the latest versions of everything in source control. Then it builds the applications. Next, it obfuscates the C# code. Next, comes the digital signatures, and finally the installer is fired off.

All of this is done through a single script. How many times do you think that I’ve messed up the build process? Yea, not many is right.

3) Use coding standards and make sure that everyone follows them.

This is a much bigger pill for an established development team to follow than for one that is just being formed. Most larger teams have some sort of coding standards they follow so that the code maintains at least a small level of consistency from one class to the next. It’s bad enough when you didn’t write the code, but to follow up after someone who writes really cryptic code can be an absolute nightmare.

During my career, I’ve been on my fair share of development teams where at least one person could have been labeled as “Does not play well with others.” It doesn’t mean they’re dumb. In fact, it can mean quite the opposite. At Clearwire, one of the developers we worked with was practically driven out of the company because his code simply couldn’t be read by anyone. He really was a very smart guy, and his code had a tendency to be very good. But when bugs were detected in his code, it was very nearly impossible for anyone else to track down the problem. Often, it was interoperability problems due to architecture changes.

But still, the fact remained that his code was simply too cryptic. There are a lot of tools out there which can help with this sort of thing. You can run them as part of your nightly build process. You’re doing those now, right? On your new, fancy VMWare image? Good.

Recently, I started a project to get the source code here at Moon River Software under control using FXCop. By doing so, I can make sure that all naming conventions are followed, and that all of the code at least conforms to a standard. The great thing about standards is that there are so many to choose from. And FXCop appears to allow users to customize the rules to some extent, further defining their own internal development standards. This is probably more time consuming than either of the previous two efforts, but code maintainability is very important.

4) Document everything that you can.
I’m a big fan of documentation, but notice that I said ‘everything that you can’ as opposed to simply saying ‘everything’. The fact is that occasionally, there simply isn’t time. Of course, that’s why you’re reading this. Try to make time to do documentation. This includes application documentation, internal process documentation, network documentation, etc.

Most teams I’ve worked on have had their own intranet and development server. Developers have access to create web pages with links to all sorts of things such as testing documentation, build environment requirements, setup requirements, source code documentation generated via javadoc or other documentation generators, etc. You know what works great for this sort of thing? A Wiki. Most small teams could benefit from setting up a Wiki to help the development team add documentation for various procedures and technical notes. Even full product designs can be done in a Wiki, because it’s a fairly collaborative environment. Chat boards can also work.

5) Create a functional spec for new projects and new versions.

There’s a difference between a functional spec, and a design spec. It’s a pretty basic difference. Functional specs describe how the software will work for the end user. Design specs describe the internal workings of the software and how different components interact with one another. The combination of the two will give you a solid blueprint for your software and how it needs to be put together.

6) Reuse code whenever you can.

No, this isn’t a license to copy-paste code. Quite the opposite. Anytime that code can be reused, you accomplish a number of different things all at the same time. First, you save time because you’re not rewriting the code to begin with. Second, you’re consolidating functionality so if bugs are found in the code, it will need to be fixed in fewer places. Finally, if the code has been in use previously, then theoretically it has already been tested to some degree. So, the quality should theoretically be higher.

7) Automate your testing, not to mention everything else that you possibly can.
I have to admit a little bit of prejudice here. I hate doing testing. It’s not so bad the first time, or even the second. Possibly the third. But by about the tenth time of doing something, it’s pretty much all I can do to keep from putting my head on the railroad tracks and singing as load as I can. Repetitive tasks are the most boring job ever devised. It should be the punishment for delinquint children. But these are the sort of tasks that can be automated. Quite easily in fact. There are probably a few dozen products on the market, all aimed right at allowing you to write fully automated test suites.

Many are so simple that you can click a button and tell it to record what you do for the next few minutes. Then after you click stop it will show you what keys you pressed, when you pressed them, where your mouse moved, and lets you add and delete new actions as if they were a movie sequence. Pretty slick stuff. Imagine writing the tests to test the testing software though. Just the other day I had to modify a script that was perhaps a couple thousand lines long.

I use CodeWright for most of my script editing. I got into it back in 2000, and have used it ever since. Anyway, I discovered that CodeWright has a Macro feature, where it will record keystrokes for you. I recorded holding the shift key, down 6 times, delete, down two more times, hold shift, hit down, delete, down two more times, hold shift, down 6 more times, finally delete again.

It took me perhaps 30 seconds to figure out how to use it and set it up. 200 macro runs later, I was finished. Now, I’m a very well accomplished script writer and could have easily parsed the file with a perl script, sed, awk, or something along those lines. It really wasn’t worth the time and effort. It was too much work to do manually, and too much work to write the script to do the work. But the macro was the perfect solution. The same thing goes for automated test suites. I think it would be hard to go wrong with an automated test suite. It’s amazing the things they can catch, especially if you wire it up to the end of your build process to install your product, load it with test data, use it, and then uninstall. All of this in the middle of the night when you’re not doing anything else with the machine anyway.


I wrote this article several days ago and waited to publish it because I felt that I was on the wrong track. It seemed as if I was concentrating on all kinds of things that a company should be doing that were related, but not exactly focusing on quality. After careful consideration, I realized that I was on the right track and simply didn’t realize it yet.

If you want to focus on quality and you try to do so explicitly, you’re going to fail. You can’t simply tell someone to write better code and think that it has the remote chance of happening. You also can’t decide to design your software better. That doesn’t happen either. At least not until Version 3 hits the shelves.

The simple fact is that you can’t focus directly on quality. You need to focus on everything around it. Focus on the processes surrounding the things that you want to be higher quality. Want higher quality code? Put a process in place for code reviews. Want better documentation for the software? Have your doc writer send the documentation to the developers to review for technical accuracy. Then send it to the marketing folks to see if they understand it. If both groups give their seal of approval, then your documentation is flawless.

Want a better designed product? Wait till version 3. Just kidding. Write functional and design specs. Then read them. Reread them. Make sure everyone else has read them. Read them again. Then execute.

It’s not exactly rocket science. But people have been screwing this up for years now, and the trend is very likely to continue. The fact is, people generally don’t take the time to improve processes because they don’t think they have the time available to do so. In fact, I don’t think that most people realize the benefit of having these processes in place to begin with. It’s amazing how much easier your life can be if you just change your focus a little bit.

By focusing on the processes surrounding the problems you’re encountering, you can modify the process to be better. This will in turn, provide higher quality in whatever it is that the process is controlling.

Share/Save/Bookmark

What do you mean it’s due Wednesday?

Posted in Daily Entries on March 16th, 2006 by Mike Taber – Be the first to comment

My “How to focus on quality” article took longer to get out the door than I thought. It’s been sitting there unfinished for the better part of a week. Late last week, I decided to talk with my CPA to get my corporate and personal taxes done. I’ve still got another month, but I suppose I should get it over with.

He emails me back to say that we need to file an extension because the deadline for corporate tax filings in Massachusetts is March 15th. I look at the calendar. It’s March 10th.

Uh-oh.

So, the proper extensions are filed, and the fees are paid. But I can’t say I’ll be making that mistake next year. Thankfully I had spoken with my attorney last week about an unrelated contract and we briefly touched upon the fact that my yearly report was due to Massachusetts as well. I thought I had another month there too. I would have really taken it in the shorts. The late fees are probably approaching the levels of the national debt.

It’s all under control now. I certainly won’t screw up the dates next year though.

Share/Save/Bookmark

Database Mistakes

Posted in Daily Entries on March 7th, 2006 by Mike Taber – Be the first to comment

Mike Gunderloy put together a great article for developer.com outlining “Ten of the Biggest Mistakes Developers Make With Databases”. It ties in pretty well with my Gatekeeper article, advocating a single point of control for database development within an application. Everything he mentioned, I myself have seen time and time again.

The bottom line is really “Know what you’re doing.”. And this of course covers pretty much everything.

I’m still working on organizing some of my thoughts for my next article on how to focus on quality, as opposed to the fact that you should. Business is growing fast though. I’m almost at the point where I’ve considered hiring an administrative assistant just to help with running things, let alone getting real work done. Dealing with a lot of the administrative stuff seriously detracts from your time doing the work that really matters.

I’ve also been doing a lot of reading of the dozen or so books I purchased last week. It’s amazing some of the contrasts I’ve found between two books which are by the exact same authors. One makes perfect sense and is put together in such a way that a monkey could understand it, that monkey being me of course. The other? Well, same authors but lets just say that the other book didn’t get put through the ringer to see if it even made sense. I read the first three or four chapters and gave up. It just didn’t make any sense, and it seemed like the authors were playing with semantics of words. Not very helpful.

In any case, these two books will be the first entries into Mike’s Bookshelf. Any geeks out there interesting in learning marketing could do well to read over my summaries prior to spending a lot of time reading random books before finding a few good ones.

Share/Save/Bookmark

Coming soon, Mike’s Bookshelf

Posted in Daily Entries on March 1st, 2006 by Mike Taber – Be the first to comment

I’m a firm believer that you should never stop learning. Perhaps that’s where my intense dislike of self-proclaimed experts comes from. That, or the fact that half the time I probably know more about the topic at hand than they do, and since I wouldn’t call myself an expert, how is it that they can?

But learning is key to not only personal development, but the ultimate success of your business. When you are running a one or two person shop, you have to learn how to do almost everything. And there are very few places in the world where you can get that sort of experience in every aspect of a business in such a short time. The fact is that you’re probably short on knowledge in a great many areas.

Many small businesses fail, obviously enough, because they run out of money. But in order to run out of money, you need to be doing more things wrong than you’re doing right. Or at least more wrong of the things that matter. To avoid that, you need to learn more about the areas you’re inexperienced in and apply that knowledge. Most software companies are started by software people.

This is a naturally occurring phenomenon. I don’t have hard statistics on this, but I would imagine that there aren’t many art majors or medical professionals who quit their day jobs and decide to write and sell software on their own. It just doesn’t happen. As a developer and self affirmed geek, I’ve never run into a technical problem that I couldn’t solve, or at least didn’t know where to start looking to find the answers I needed.

Move outside the realm of technology though, and it’s easy for a geek to flap about like a fish out of water. When it comes to things like marketing, positioning, advertising, payment processing and other similar business issues which are not necessarily technological, geeks as a whole are just out of their element. Throw them a Z-transform any day of the week and it’s as good as solved. Ask them who their product is designed to be sold to, and the answer is invariably “everybody with a computer”. The ones who aren’t out of their element already own their own successful startups.

To help me achieve and maintain my status as a jack of all trades master of none, I read a lot. Whether they’re blogs, or books it doesn’t really matter so long as the content is useful. The problem I’ve found, is that it can be difficult to sort the wheat from the chaff at a glance. I can’t imagine that I’m the only one suffering from this problem, so in an effort to help others fighting the same sort of problems, I’m going to introduce Mike’s Bookshelf in the next few weeks.

This past weekend, I ordered 12 new books from Amazon.com. Only one of them was a technical book. The other 11 were about various marketing techniques, advertising techniques, and generally helpful stuff for geeks like us who really just don’t know any better. If you took some classes on marketing or economics in college, you’re probably a few steps ahead of the curve. Unfortunately, my educational program was a beast. Weighing in at a whopping 199 credits, the undergraduate Computer Engineering program at RIT was anything but nice. And with the exception of a single elective, every one of our courses was required. Sure, I could have taken economics to satisfy my liberal arts requirements, but instead I chose things like Philosophy of Religion and Psychology.

In retrospect, I chose pretty poorly if I wanted to have any sort of decent business background, but it’s about 10 years too late for regrets. Accounting for Dummies is actually a decent book, incidentally. It probably saved me at least a quarters’ worth of economics classes, I probably remember just as much as I would have, and it was around $1,180 cheaper.

But “Mike’s Bookshelf” is where I’m going to start posting book reviews of the various books I’ve purchased over the years. I’ll probably post a few technical books here and there, but it will focus mainly on non-technical books, because I think those will be the most valuable to those who are starting their own businesses, or thinking of doing so. Some books will be well written and helpful. Others will not. Some will be dated, and others more recent.

Regardless of the topic or when it was written, I’ll try my best to give everything a fair shake. If you think I haven’t done so, let me know.

Share/Save/Bookmark