Archive for February, 2006

Quality is not a feature

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

For the past several weekends, I have been entrenched in the truly terrible task of stripping wallpaper and getting the walls ready for painting. I’m probably about as far from being a violent person as you can be without actually being a pacifist, but were Jean-Michel Papillon still alive today, I’d probably beat him to death for inventing wallpaper.

The painting itself doesn’t bother me. I spent an entire summer of my college years painting the walls in a high school. No, it wasn’t a penitential mandate from the state, and yes it really was a three-quarters time second job that I got paid for.

Back to the point, as we were just finishing up the first coat of primer, my wife asked me if we should bother doing a second coat of primer on the walls. My immediate answer was yes. We weren’t going to skimp on the primer.

This doesn’t date back from my brief brush (no pun intended) with a career as a painter. My answer came from the knowledge that to do a good job required at leat two coats of primer, and anything less and it would just be shoddy work.

This past weekend, I went to get a haircut and on the way back I passed a car dealership. Now, I look at cars whenever I pass a used car dealership. I’m not sure why. I have no intentions of pulling in, but I still like to look as I drive by. It occurred to me while I was looking how happy I was that I traded in my old car about a year and a half ago. I had been driving a 1997 Saab 900S, which after eight years was really on its last limb. I had only owned it for five of those eight years. Now don’t get me wrong. I loved the car when it was running well.

The key of course, is when it was running well. It didn’t always run well. In fact, it seemed like every time I turned around I had to sink a lot more money into it. From the year after I bought it to the time I got rid of it, I spent on average about $2,000 per year in addition to car payments fixing it. The serpentine belt, the alternator, rotors, etc. If it was expensive, it broke on my car at one point or another.

Eventually in December of 2004, I traded it in for a 2002 Honda Accord. One of the key factors in my decision of what to purchase next was how expensive the new car was going to be to fix, and how often I would have to fix it. This entire train of thought came about because of the used car dealership that I saw, and the train ended with “I’m glad I bought a Honda. I haven’t had anything go wrong with it since I bought it.”

This happened as I was drawing near the end of Moon River Milestones v1.1.0 development, and it got me thinking about quality in software products.

Hypothesis: Would people pay a premium for quality?
My immediate reaction to this question was yes. I mean, who pays more for software with a lot of bugs in it? For that matter, who in their right mind pays more for anything with more defects in it? Well, read the latest Consumer Reports for car ratings. The BMW 7 Series of used cars from 1998-2005 is ranked as one of the Bad Bets. So is the Lincoln Navigator, Mercedes-Benz CLK, and a couple of Jaguars, all of which are pretty high on the price list.

I will concede that quality and price are not the only considerations people make when purchasing a new car. But there should at least be some correlation between price and quality right? Who in their right mind doesn’t value quality!

Well, let me beat up on the car industry a bit more. Recently, GM announced a restructuring plan to hopefully save them billions of dollars. Looking at their Wikipedia entry shows the plants that they will be closing. Let’s put this next to the J.D. Power and Associates listing of the Assembly Plant Awards for highest quality. Notice anything?

It would appear that the Oshawa #2 Ontario Canada plant is going to be closed, and the Oshawa #1, Ontario plant is going to be scaled back to eliminate the 3rd shift entirely. Interestingly enough, both of these plants are on the J.D. Power and Associates lists for outstanding quality listed as the number one and number two plants.

Perhaps its just my overly cynical view of public companies and thier quest for increasing their stock prices at any expense, but wouldn’t you want to increase production at these facilities to compensate for the ones that are producing garbage?

Apparently not. Somehow, their marketing and sales forces are going to overcome the fact that they’re selling crap to the consumer by hiding behind a limited warranty.

“Hey, if you want me to take a dump in a box and mark it guaranteed, I will. I got spare time.”

From the movie Tommy Boy

On the other hand, you have companies like Hyundai offering outstanding warranties on their cars that would have seemed insane 20 years ago. They can do this for only one of two reasons. Either their cars are genuinely good and can last until the end of the warranty, or they are made so cheaply that they can fix all of them, and still make a profit. Take a wild stab in the dark at which of those two companies are growing, and which is shrinking? I’m willing to bet that part of it is due to quality. In fact, Hyundai has bet their reputation as a car company on their quality and you know what? They’re beating GM at it. True or not is a different story, but they’ve proclaimed their quality to the world, and the world is listening.

But these examples are cars, not software. The fact of the matter is, that my entire argument relating cars to software is fundamentally flawed. It’s unfortunate that I realize this now, after writing over 1,000 words on the topic. I’m probably lucky in the respect that writing helps me think things through. That’s why I write a lot of things down. In the end, it boils down to much less than I originally wrote. Most of what I write down I end up throwing away because it sucks. But the journey does tend to yield a lot of good results.

The fundamental flaw in my argument is that software and cars are like apples and oranges. You can’t effectively compare them on a general basis. All cars have a common purpose. They get you from point A to point B. There’s a lot of other features as well, but they all basically do the same sort of thing. That’s why the differences are features. That’s not the case with software because software functionality varies widely between applications. It accomplishes something. But beyond that, there’s very little you can generalize about. It solves a problem maybe? I don’t know how well games fit into that category unless you count boredom as a genuine problem. And if that’s the case, then you’re either a games developer or in college and should be studying instead of playing Quake.

There’s plenty of software out there that I think is absolute crap, but still sells like hotcakes. And I don’t mean crap in the sense of the functionality of the software because some of it could be really useful. I mean crap terms of the quality, such as software that is useful, but crashes every third click on the gui, and those sorts of things. It’s positively insane how poor some types of software work, yet it still ends up on lots of computers. Don’t believe me? There’s software that is distributed by Dell which uses some sort of watchdog to detect when the hardware is locked up. When it detects a lockup, it reboots the system.

At the core, it sounds pretty simple. Quite useful in fact, especially for web servers. It stops working, so the hardware reboots the machine to get your website back up and running without any user intervention. In practice, it’s not nearly on par with where it should be. I’ve been told by people who have this software that they disable it on most of their servers because of its flaws. Isn’t that Petarded?  It’s sole function is to detect a hardware lockup and reboot. How complicated can it be? What flaws could it possibly have that are that bad?

It turns out that the flaw is that the hardware watchdog blue screens the machine quite regularly. Ummm…. yea. Just be thankful that this software doesn’t run the power steering in your car yet. They might want to focus on quality, don’t you think?

Quality sells, but not in the way that you think.

If you asked me whether or not I would buy another Saab, I would likely tell you no. I liked my car, but it was the flaws that I remember more than how enjoyable the car was. My Honda has been running without anything more than regular oil changes and minimal maintenance for a year and a half now. Currently, it is 4 years old and running strong. Would I buy another Honda? Most likely. Would I recommend one to my friends? Of course.

Go back and reread that, because there are two very important things in there. The first is, would I buy another. The second, is would I recommend one to my friends. More importantly are my answers to the questions. I think these are key principles that really do apply to software.

If someone is willing to buy more of your product because they like it, then I believe that they are just as likely to recommend it to people they know. Perhaps not actively as an evangelist, but if a friend said they had problem xyz and your product solves that problem, this particular someone would recommend it to his friend because it works to his satisfaction. Even better is when your product is so far above and beyond that of every competitor that these customers become evangelists and do your marketing for you.

When a company spouts off lots of rhetoric about how great their software is, how it will solve all your problems, make you breakfast in bed, etc, we take that with a grain of salt. Marketers lie. All of them. Seth Godin says so, not to mention there’s a website that says this too, so it must be true.

But when you hear how great something is from your colleagues, classmates, friends, drinking buddies or whomever, you take it a little more seriously. It becomes more credible somehow because you trust those people. Maybe not with your life, but in a pinch, who would you trust to save your hide, your best drinking buddy, or the guy hocking the software that in addition to its original purpose, makes breakfast in bed? It’s not a hard decision.

Having current customers buy more of your software is a great concept because you already have a business relationship with them. You are a known entity. Customer evangelists are the single greatest accomplishment a company can achieve because your product is good, and your customers love you for it. Apple has lots of these. It’s a long, hard road though. So, how do you get there?

Focus on Quality.

If you make a conscious effort to focus on the quality of your software, you will probably see less of an immediate impact on your sales than if you implemented new features. I would venture so far as to say that I am sure of that. Quality doesn’t happen overnight. It takes a lot of time, effort, and a commitment to quality. In time, assuming you had a decent product that was desired in the market to begin with, those efforts will likely pay off tenfold.

For a smaller company, focusing on quality can be really hard to do, especially for new products. A version 1.x product typically doesn’t have nearly as many features as the well established competitors do. It doesn’t have the established customer base and steady revenue which would provide the company a position where they can focus on quality. In fact, the smaller the number of developers in the company, the harder it is to focus on quality because of time constraints. Their time must be divided among bug fixes, new features, customer technical problems, one or more products, and a host of other commitments.

It gets worse as time goes on and your business grows. More customers means more support calls, and more technical problems. Unless you focused on quality from day one, as the number of customers rise, so will the support calls. The only way to fight this is to make your code virtually indestructable, and that means focusing on quality.

Focusing on quality will reduce bug counts at the cost of longer development cycles and fewer new features. By talking to your current customers, you can find their pain points in your own software. Perhaps some of the menus are too confusing. When you learn this, fix it! This will allow you to fix the software, reducing the number of support calls from current customers while increasing the number of sales. The net result is the company receives more money for the same number (or fewer) support calls. This frees up your time for other things, such as implementing new features, intensifying the quality of your product, or working on other products.

Conclusion:

While it’s hard to say with absolute certainty whether people would actually pay a premium for software that is guaranteed to be of a higher quality, the fact remains that most people (who don’t run public companies) value quality. Quality isn’t just a word. It’s a commitment. And if you think otherwise as you attempt to address it within your own organization, you’re going to fail.

You can’t pay lip service to quality because it shows. People notice. No amount of lying from your marketers is going to tell someone that your software will rock their world when it crashes twice a day. Polishing an application to look great is related to quality, but not quite the same thing. Buggy software that looks great is still garbage. The code has to work flawlessly every time, and when it doesn’t, you need to know about it. This is where customer feedback forms come in.

When you focus on quality from day one, you set a prescedent for the future, that poor quality is not to be tolerated. Nothing less than perfection is acceptable. This doesn’t mean you can’t make mistakes. It simply means that you don’t let bugs go unchallenged. Anything more complicated than a Hello World! program is likely to have bugs. Heck, I’ve misspelled the word Hello in a Hello World! program before because I was typing too fast. Finding bugs or customer problems and allowing them to persist for too long is when you start running into problems.

In my next article, I’ll be examining many different ways that you can improve the quality of your products.

Share/Save/Bookmark

Another “Milestone” completed

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

Well, Moon River Milestones v1.1.0 is out the door, and it’s time to turn our attentions towards a pair of other pressing matters. First, is the conversion of our website from the older and more venerable ASP code to C#.NET.

“Why the change? Isn’t it good enough as is?”

Well, not quite. Part of the problem boils down to maintainability. A long time ago, I got hooked on ASP because it was far easier to maintain than Perl for web based programming. Later, PHP came along. There’s not a lot different functionally between the two if you know what you’re doing. But maintainability is still an issue.

Converting the website to C# allows us to keep all of the website source code, including images, text, etc. all in the same solution file within Visual Studio. This is an incredible benefit. The mere fact that I don’t need to switch between CodeWright and Visual Studio should be reason enough, but there’s certainly more. The ability to use the same code libraries between multiple projects is a key part of our corporate strategy. Moon River Milestones is written in C#, as is the license code generator. ChitChat.net and SPROC Build are also C#. Now the website is being converted to C# and Aurora is being built with C#.

See a pattern yet? Consolidating nearly all of our code in a single solution file, and sticking with C# allows us to concentrate on the code, not on getting our brains on the right path in terms of the syntax we should be using to print out a string. It’s the same code, regardless of the project.

When Aurora hits the scene, you’re going to start to see the beginnings of another pattern. I won’t spoil the surprise yet. You’ll have to wait and see how Aurora unfolds.

Share/Save/Bookmark

Milestones v1.1.0 will be released this weekend

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

It’s always nice to finish up something you’ve worked very hard on. This weekend will mark the completion of Moon River Milestones v1.1.0. A small milestone for Moon River, but a new milestone nonetheless.

Testing revealed some rather embarrassing bugs, to be sure. For example, I recently added anchor links for the text descriptions of issues that were edited. I had decided that dynamically generating these links would be a pretty cool feature. So, for example, you can add a description like this:

“Mike says that issue 47 isn’t a big deal. This one is similar, so we should probably just close it.”

Prior to displaying the text on the page, it would search the text word by word for issues that it should link. In this case, the text ‘issue 47′ would link back to issue 47. It’s case insensitive and will automatically link anything that matches issue, case, bug, ticket and a few other words, followed by a space and a numeric value. That way, people aren’t restricted by my terminology in how they use the product.

The cool thing was that after realizing that it was a link to another issue, the code would look up that issue to get the status. If it was an open issue, it would assign the text “Issue 47 is Open” to the title tag for the href link, and leave it as is. If it was resolved, the link would be in italics, and a Closed issue would be linked, italicized, and stricken, like so. If the issue didn’t exist, it would not be linked, so the user can’t be redirected to a non-existent issue, automatically redirected back to the main gridlayout page and left wondering what happened to issue 47365.

This apparently wasn’t tested real well during development. If the issue was resolved, it was attempting to reuse a connection string to the database from a connection that was already open. Those familiar with .NET will realize this is a no-no, since you can’t access the ConnectionString property of a connection while it is open. Bad programmer. No Dew.

Everyone makes mistakes I suppose. There were a lot of ‘little’ bugs like that which were found, squashed like PHB’s should be, and then the whole project was rebuilt and retested, just to be sure that nothing else was broken. This process was gone through perhaps at least half a dozen times. Most of the code was pretty good, but there were a lot of last minute tweaks that I snuck in too, most of which were actually targeted to Version 1.2, but I knew it wouldn’t be hard to add them in and should make for a better product.

Of course, there’s one that I overlooked. I shouldn’t have overlooked it because it’s tracked in Milestones, but it’s too late now and is so incredibly minor that I’m simply not going to worry about it. The copyright date in the footer still says 2005. Issue 343 clearly states that the footer needs to be updated with the latest version and an updated copyright date. I missed the date though because I didn’t read both parts of the same issue. It should have been tracked as two separate issues.

I made a mistake. I’m only human I suppose but I doubt that’s my major character flaw.

This weekend, the online trial will be updated with the new software, a press release will be drafted, and the software is already in the hands of some early customers. Once things settle down a little bit, it’s time to get cracking on Aurora. Some of you may have noticed that the timeline I set forth at the beginning of the year is not only tromping along without a whip behind it, but March is fast approaching. Can Aurora be ready by the end of the month?

My guess is probably not. Development time for MRM v1.1.0 was extended by three weeks due to a home painting project that ate up three full weekends of work, plus several days in the middle of the week. This painting project is still ongoing, and will be completed a week and two days from today at the very latest. But Aurora isn’t a terribly complicated piece of software. Oh, it’s going to be a pretty damned useful piece of software if I do say so myself. But I can’t imagine it will take very long to write because I spent so much time designing it.

I think the design was probably the hardest part of the project. There were some really tough decisions that I had to make. I’ll be able to elaborate on some of them after launch, but let me say flat out, I spent many a night awake in bed agonizing over some of the decisions that I had to make.

Share/Save/Bookmark

Milestones v1.1.0 complete

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

Well, it’s done and testing is underway. So far, I’ve only found a couple of issues and they’re pretty minor. No sense in wasting time talking about them though. The time would be better spent on fixing them. I expect that the new version will be ready for all of our customers and live in the trial area by the 28th.

In other news, work on Aurora is being delayed due to design issues. The problem that Aurora addresses actually has about 50 different variations. The design problem revolves around solving multiple variations in an attempt to expand its presence in the marketplace. I really can’t say much more than that, since it’s just vaporware at the moment but I think it will certainly satisfy the needs of a lot of people once it hits the market.

And of course, the beta testers we have contacted about it are chomping at the bit to get their hands on it. Ah, the trials and tribulations of finding a product that people desperately crave.

Share/Save/Bookmark

The Gatekeeper

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

It’s fairly obvious that whenever you work on a development team, everyone fills different roles. This can sometimes make it difficult to evaluate the individual contributions of particular team members, especially when their roles overlap to a large degree.

These roles vary from team to team, as do specific titles but most are essentially the same. You have the grunt, who does a lot of coding. You have the architect, who does mostly design work. There’s a team leader, who puts together a schedule, assigns tasks, and generally tries to make sure things get done on time. Most people fall somewhere between the grunt and the architect. Some grunts do design work, and some architects write code, so obviously there’s some overlap.

What I’ve noticed is that most teams have skillsets that overlap in so many different areas that it is pretty rare when one person truly owns something. There is one place where this becomes a serious problem: databases.

If your application uses a database, you need a database gatekeeper.

Every team that works with databases needs a gatekeeper for each application they are working on. It doesn’t need to be the same person for each application and arguably, is better if it is not. But you need someone to fill this role nonetheless. The gatekeeper I will focus on is the database gatekeeper. You can easily argue for other gatekeepers. Others that come immediately to mind are gatekeepers for the build, source code check-ins, branches, website applications, code versioning, bug tracking, etc. The fact is that any important part of a project could probably use a gatekeeper to keep things working smoothly.

Even on development teams which rely extremely heavily on databases, it has been my experience that there are perhaps only a small percentage of people on the team who truly know how to use a database effectively. Most developers view a database as an overglorified list of objects for which exists solely so they don’t need to worry about important details like saving the data or maintaining it between application starts.

This is not only inherently wrong, but it’s a dangerous line of thought. The fact is that a database can be an extremely complex part of your software and whomever designs it really needs to know what they are doing. Database design is very important for several different reasons. A poorly designed database is like a poorly designed algorithm. It still works, but not nearly as effectively or as efficiently as it could. Operations can take orders of magnitude longer if they aren’t done correctly.

If not used properly, a database can also end up filled with a lot of useless data. Consider this simple example. You’re building a nifty little forum for your website. You create a table called ‘User’ to store… err… well, the users. And you create a table called ‘Topic’, and ‘Post’ to store the topics and posts to that topic. Seems pretty simple.

But there are some basic concepts that must be followed. For example, what happens if you delete a user? Are all of the topics they created deleted? Are all of their posts deleted?

Yes, they are deleted. If someone comes in and spams your forum, perhaps you do want to get rid of everything they did, especially if it was a script that logged in and posted into every single topic.

The answer is also, No, they are not deleted. Perhaps you do routine maintenance and delete users who have been inactive for a period of time. You then implement a mechanism in the code to state that a post was made by a user who has been deleted.

People who don’t know how to use a database tend to fall into one of these two categories because they simply don’t know any better, and not because they made a conscious design decision. Their expectation is that the code they are writing will take care of every situation and will handle all of the business logic. These are the developers who have lots of extraneous logic in their code to handle referential integrity checks, and use a “select max(id) from table_x”, then increment the value by some constant value to determine what the id of the new element they are inserting should be.

This is not how it’s supposed to work. Every database I have ever used has some form of sequencing to help you determine the next identifier, be it a sequence in Oracle, or an Autonumber in SQL Server. The referential integrity should be enforced by the database with foreign keys. Unique data should be maintained unique with constraints. Every database comes with a set of functions that help you maintain the data.

“The purpose of a database is to maintain and manage your data”

I’m going to avoid getting into how a database really should be used. The fact is, that someone on your team should be assigned to be the Database Gatekeeper. It is his or her job to make sure that the database is designed correctly to begin with. If a developer needs to add a column to a table, it should be cleared by the gatekeeper. Not only should it be cleared by the gatekeeper, it should be him who adds the column to the database scripts.

What good can possibly come of this?

For starters, you get a solid naming convention. People experienced with databases tend to have a naming convention they use to help them figure out what the relationships between tables is by glancing at the database schema. Feel free to try using an established standard such as Hungarian Notation.

“The great thing about standards is that there are so many to choose from.”

Of course, this only gets you so far. What about the use of ’s’ at the end of table names? Some people will name a table ‘User’, and others would name the same table ‘Users’. Mostly, it’s a matter of opinion. My personal preference is to avoid the use of ’s’ at the end of a table name unless the table is used (solely for) relating two tables to one another. Regardless of your mechanism, at the end of the day, don’t you want all of your database tables to follow the same convention?

This is where a gatekeeper comes in handy. Since it’s his responsibility to make the changes, it is also his responsibility to make sure that those changes adhere to the established convention. One day when your database gatekeeper is long gone, the next one can look at the database design and at least have a chance of making changes without making things difficult for everyone else.

So far I’ve only addressed naming conventions. What else can a database gatekeeper can do for your team?

Prevent data redundancy.
Your database gatekeeper can tell you if the data you want to add to the database already exists. Having been the gatekeeper on a team before, I can’t count how many times I’ve prevented a developer from storing redundant information in the database. These redundancies are not only confusing, but waste space in the database.

Hard drive space is generally cheap these days, but what about access speed or the cost of storing that extra data? A pre-existing column might have been indexed, while the new one being created is not. Backup applications need to store that extra data as well. Both of these have hidden costs that a developer who is intent on implementing a feature might not think of.

Enforce database integrity.
Your database should enforce the integrity of your data, not the application code. When a database requires that relationships exist between tables, you can’t insert or delete data without satisfying that relationship. Using a sufficiently complex database merely as a storage center will cause you innumerable headaches trying to root out data inconsistencies. Most developers find these restrictions to be annoying to no end. “I want to delete this data, and the database won’t let me! Stupid database. I hate this thing!” That’s why they don’t use foreign keys and constraints. The fact is, if the database is preventing you from doing something, there’s probably a good reason.

Use the right data types for the job.

In SQL Server, it’s very easy to make a column of the type int. Too easy in fact. Enterprise Manager was/is a great tool, to be sure, but it certainly gives too much power to those who might not know what to do with it. Most people use an int without thinking twice about it, but is it really the right data type for the job? In SQL Server, anything that’s likely to go over 2 billion is probably not a good candidate to be an int. Similarly, any number which isn’t going to exceed 255 isn’t a good choice for an int either. Unicode, non-Unicode data, and variable length data can have serious impacts on the resulting data storage.

Using Unicode where ASCII text is being stored immediately doubles your storage requirements. The difference between 50 and 100 bytes doesn’t sound like a lot, but it can cost your customers money, nonetheless. Imagine using the wrong data type on every single column in a table because a developer simply didn’t know any better. Companies are pretty paranoid these days about backing up their data, and although hard drives are generally cheap, RAID 5 isn’t. Tape drives are terrible to work with, and every byte counts. An extra 100 bytes in a single row can result in 2GB of extra data in a 20 million record table. Multiply that by 100 tables and you run into some serious storage problems. Reloading a database in its entirely presents its own problems.

SQL Server 2000 ships with 27 built-in datatypes. Are you using the right ones?

Index important bits of data for speed.
Your gatekeeper can help speed up certain operations by tuning the indexes on the database. In laymans terms, it means building a cache to help find certain bits of data quicker. If a specific operation in your application is too slow, talk to your database gatekeeper and see what he can do. He might be able to speed it up by a factor of 100 without a single algorithm change in the application code.

Use Stored Procedures for complicated operations.

While Stored procedures are somewhat new to mySQL, they’ve been around for years in SQL Server and Oracle. Using a stored procedure moves some of the business logic out of the application and into the database. This is faster for a number or reasons, first and foremost is that the data gathering is done on the database server instead of over the network. Stored procedures also offer more security in applications by preventing SQL injection attacks.

Use scripted operations for all changes.

When I worked for Wegmans, it was departmental policy to refuse any database changes which were not scripted. While security certainly played a role in this, reproducibility did as well. If table changes were made via a gui, data is loaded, and then the database server crashes, how can you be sure that everything is restored exactly the way that it was before if you used the gui?

The short answer is that you can’t. Most tweaks are small in nature, but even minor tweaks can have huge performance impacts, especially when you have a database that is several terrabytes in size. A database that is entirely scripted is much easier to manage. It is easier to test, and easier to tweak for different releases.

Intelligently choose relationships.

I’ve seen people use descriptions to maintain relationships between database tables. This is bad practice at best, and assinine at worst. Descriptions have a tendancy to change. And if someone is using it to maintain relationships between tables, you will need to change it in every table it occurs. Without a gatekeeper, it will be difficult to track down those occurrences. If your application is using a description field as a table relationship, you probably have more serious problems.

What is the single worst way to choose a gatekeeper?
Use his resume. I recall interviewing someone who seemed to have pretty extensive SQL Server 2000 experience on his resume with the intent that he would be our database gatekeeper. Our team was really lacking in people who had database experience, so I was really looking forward to the interview. I asked him some database questions, and he seemed to know what he was talking about. Then I asked him about triggers, and what he had used them for.

He explained a very elaborate system of triggers that he had implemented to delete data from a very large database that was his current project. To simplify things, recall my example of nifty forum software above, imagining that he was attempting to delete a user and wanted to delete all of the topics the user had created, all of those topic posts, and delete the posts of that specific user. A trigger is a database mechanism for intercepting inserts, updates or deletes to the database and performing additional operations before the actual insert/update/delete takes place. In this case, he would delete the user, then the trigger would intercept the delete.

This trigger would in turn attempt to delete the Topic, thus firing a second trigger, which attempted to delete the Posts that the user had made. The original trigger would also delete all of this specific users’ posts. Traversing down the chain of triggers and then back up again results in the ability for the developer to delete a user and all associated data, while maintaining the database constraints, and referential integrity.

After patiently listening to his explanation of how he had used triggers, I asked him how well the resulting implementation worked. Apparently, not very well. Data inconsistencies were still being found as some of the table hierarchies traversed 10 levels deep. It was extremely difficult to track them down. He had spent the last 3 months trying, and still wasn’t finished. I asked why he didn’t use SQL Server’s built in ‘Cascade Delete’ and he had no idea what I was talking about.

After about five more minutes of questions, it quickly became clear to me that this developer had some serious holes in his knowledge of databases and wasn’t going to cut it as our database gatekeeper. He understood that referential integrity was important, but he lacked sufficient knowledge of the tools he was using to do it properly and efficiently.

How do you choose a good gatekeeper?

This is a lot harder to answer. Even the person I interviewed in the above example would probably not have been a terrible database gatekeeper if he weren’t by himself. I included the example to prove that a resume is not a tell all indicator of suitability for any given task. I think that so long as the person you have chosen has a decent knowledge of more than one type of database, and has a genuine interest in learning more about them, he is likely to be a good candidate. Someone who used to be a DBA would be an excellent choice, but ex-DBA’s turned developer are hard to come by.

Another possible solution is to use a couple of people who have database training to discuss any database issues. Two heads are better than one, and while a lot of their knowledge may overlap, some of it is likely to be distinct. People hate committees, but this can work well on some teams without overloading any one developer or trampling on their egos.

Conclusion:

Every development team using a database could gain some benefit from a full time DBA. Unfortunately, very few of us are going to have that luxury. Your best chance for avoiding some nasty database snags is to assign someone to the role of Database Gatekeeper. It is their responsibility to maintain the database design, make changes, and be the resident database expert for that application. It will save you time, money, and ultimately a ton of headaches.

Share/Save/Bookmark

The calm after the storm

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

It’s not really all that calm to be honest, but it’s certainly not the fire and brimstone of yesterday when nobody knew what to think, false rumors were getting started, and obscene emails were coming in.

Perhaps one of my goals for the year should have been “Try not to get noticed until after version 1.2 of MRM comes out”. At least by then I could have had three products for people to look at instead of just MRM. I still don’t have ChitChat.net listed as a product for sale on Moon River Software’s site yet, nor have I had time to integrate it into the main MRS site. Or into my blog for that matter. I suppose if ChitChat had been available yesterday, scrubbing it of the obscenities might have taken most of the night to do.

It takes time to do that sort of integration, and that is time which I’m currently selling to the steadiest bidder as a consultant to pay the bills. I certainly don’t regret being a consultant, but working double time is a bit harrowing. Tack on the fact that I’m sick right now with a sinus cold, and I’m really just not having any fun, all things considered.

My long winded explanation seems to have stopped short a prolonged fury. There are still the few naysayers, but I expected that. There’s 10% of the population whose minds you will simply never change, no matter what you say or do. What good is a well intentioned argument if the other party doesn’t care what you have to say? It’s like arguing with a 2 year old. “But why… but why… but why…”.

One JoS reader commented that I seem to have a lot of interesting things to say and a lot of history behind me. I’m no spring chicken anymore, that’s for sure. I have plenty of grey hair to prove it. Perhaps some good will come out of all of this after all. I will definately keep writing. I have a number of articles that I’ve stubbed out as things to work on, but just haven’t finished most of them. I’m don’t think I’m nearly as entertaining as some writers, and I’m definately not as successful as most of the people you probably have on your own blogroll, so your next question is, why should you bother listening to me?

Everyone wants to be a success story and everyone likes reading about them. People like Joel, Paul Graham, Steve Pavlina and Eric Sink are natural attractions because they seem to have succeeded on their first attempts. I really think that is the exception, rather than the rule. A lot of people simply crash and burn. Me? I’ve crashed and burned twice so far on my own. Four times total if you count companies I wasn’t running myself. Will MRS crash and burn as well?

I don’t think so. In fact, I can say pretty confidently it will not crash and burn.

I never had that warm fuzzy feeling inside me with the other two companies I started, or that voice in my head that was screaming “You need to get this done because it’s going to be huge!”. Currently, the voice is rather subdued and is saying “Take your time, and don’t rush things. Just focus on what needs to be done right now.” The simple fact of the matter is that in the short months that MRS has been in existence, I’ve made more money than both of my previous companies combined, and then doubled. My consulting efforts are definately paying off. I’m learning to become a better writer, and the software work I’ve been doing has been coming along nicely.

It’s different this time. Completely different in fact. Everything seems to be falling into place, and working out for the better. Eventually at least. Over the years, I’ve worked in two failed startups (2K Innovations Corporation and Clearwire Technologies), created two of my own failed startups (Yako Entertainment and Game Thoughts), worked at Wegmans, the #1 company on Fortune Magazine’s list of 100 Best Companies to work for, and stayed with yet another company till it was bought out for around $65 million dollars.

I think that the diverse experiences I’ve had has a lot to do with this being different. You see, when you fail at something, you undergo a learning experience. As bitter as the experience can be, you may not realize what you have learned until years later. Some companies get lucky, hitting the nail square on the head in the first shot. “Woohoo! This is a piece of cake!” they say. It isn’t until their second, third, or maybe even their fourth project that they begin to realize they were insanely lucky. By then, it’s too late and their company is spiraling out of control down the toilet bowl faster than a lawyer runs from Dick Cheney.

Being lucky means that you didn’t actually learn much other than the idea that business appears to be really easy. This is bad because running a business is not only hard, it’s incredibly hard. You can become too complacent and if things start to go awry, you try and ride your luck through to the end, falling face first in the dust because you thought there’d be a vat of styrofoam peanuts at the end of the ride to catch you. “What the hell just happened?”.

Well, you didn’t screw up enough early on. Luck can only get you so far. But a history of failure is often more than adequate to teach you what not to do and prepare you for the real world. A world where you are in charge calling the shots. You become a penny pinching miser, and are able to save money for a rainy day because you realize the sun isn’t going to be shining on your back forever.

My point is that over the next 18 months, you’re going to see some incredible advances towards profound success here at Moon River Software. Come back and visit every so often. You’ll see.

Share/Save/Bookmark

Joel on Software readers up in arms - A view from the other side of the fence

Posted in All Articles, Business, Moon River Software on February 13th, 2006 by Mike Taber – Be the first to comment

Interesting… very interesting. So, after a long day (9 hours plus 30 minute lunch) of consulting, I come home to do my nightly routine. Check my email, check my traffic, do some programming till am, go to bed… whoa, wait a second… that’s odd. Traffic spike. Not just one site either.

Where’s it from though? Let’s see here… use 123LogAnalyzer… click Analyze…discuss.joelonsoftware.com? Odd. I haven’t been there in a very long time. type-type-click-click…

Are you kidding me?

I think I’ll start off with one very important piece of information, because some people have obviously got the wrong idea and like a disease from a bad zombie movie, they’re spreading it.

“For the record, I don’t have, nor have I ever had access to FogBugz source code.”

No, I didn’t copy the source code, translate it, pirate it, steal it, or anything else close to <insert your favorite words from a thesaurus for copying here>. And yes, I know it looks similar. Not that I think certain individuals are going to believe me(there are always a few diehards), but I still have on my whiteboard a note to myself to write up the design history of Moon River Milestones as of 1/22. Obviously that didn’t happen, and this post is going to be seen as reactive when in reality, I just never got around to writing the article.

For those of you who want to hear the full story I’ll start from the beginning.

Back in 1998:

Back in 1998 I started writingreal web based software applications. I’d written incredibly dumb things, like page counters and stuff like that, but nothing of substance. One of my very first web applications was for the company I worked for in Buffalo, NY named Clearwire Technologies. The company was a fixed wireless ISP offering fractional T1 Internet access via microwave radios in the 2.4GHz unlicensed spectrum. In 1998, nobody knew what that meant. In today’s terms, think of the wireless card in your notebook with range of up to 25 miles, limitation being it was connected to a satellite dish outside the building. Math and geography majors will note that this range is about the maximum line of sight due to the curvature of the earth. The range was weather dependent, and had a lot of problems with clouds the way any satellite dish used to.

My role at Clearwire was twofold. I was split between the MIS department, and the Engineering department. I would install software, fix computers, and write embedded systems code. I was cheap enough at the time that they could afford to have me working by the hour for 45-50 hours per week and not care too much about paying me overtime. I worked with real time compression algorithms, load balancing, fault tolerance, and was the backboard for one of the senior engineers to bounce ideas off of. I was sort of his 5 year old whose purpose was to see through the intricate plot of the evil overlord.(see #12)

But I digress.

The first full fledged web application I wrote for them was an online ordering system written entirely in Perl. A full year and 50,000 lines of Perl later, it was time for version 2.0. Yes, it really was that much Perl code, and by the end, I despised Perl. (I actually enjoy working with it these days.) You see, as sad as this is going to sound, they were ok with paying me by the hour for a couple hundred extra hours of work, but to pay a few hundred dollars for a real database to use was asking far too much of them. I would have given up body parts for even Access at the time. I had to use binary files to build my own database in Perl. Try that for a weekend exercise. It wasn’t a great solution, and it certainly didn’t scale well, but it worked well enough. The lack of scalability was a direct result of the fact that I didn’t have a real database to work with and didn’t have the time to spend on coding a ‘real database’ with B-trees, and indexes, and all the nice stuff that comes built in.

Eventually, the management was convinced that it was time to put some real financial effort into the project because my software was supporting nearly every operation they had. They brought in a consultant team to contract for the job. At 11 am on a Tuesday morning, I sat in a room with all of the senior management of the company who had flown in from the Dallas office and listened to the presentation. My boss told me it was probably a good idea if I kept my mouth shut. As annoyed as I was at having my pet project ripped out from under me, I had (and still have) the utmost respect for his opinion and guidance, I kept quiet and listened.

After about an hour of presentation hoopla, our CEO got a bit impatient and asked the ultimate, presentation ending questions. “How much will it cost, and when can we get it installed.”

“Umm… err… Well, we’d need to customize it to your needs and that could take up to six months.” came the reply.

“Well as is, how much does it cost, and when can we get it?” Brian asked again.

“Umm… uhh…” foot shuffling “$20 million, and it will be done within 18 months.

About that time, it was evidently quite clear that vaporware had entered the picture and these two guys were looking for funding for their own company more than anything else. It was the dotcom era of throwing money around like bottled spring water and these guys saw dollar signs. You see, they didn’t have a product. I don’t think they even had a development team. I’m sure they were going to outsource the whole thing to India for $1 million and pocket the other $19 million. Our CEO walked out, and within 5 minutes my boss, the two presenters, and only one or two other people besides myself remained.

Clearwire decided that they’d take a chance on me, and let me go through with building their online system while keeping close tabs on my progress.

Fast forward about 2 years, and I was working elsewhere looking for ways to make money with web based software. After all, dot coms were at their peak making money hand over fist. Or at least seeming to. In reality, they were spending money hand over fist, but I wouldn’t have known the difference then. All I knew was that I had been in the Buffalo office where we were getting the scraps of all hardware and software while our Dallas office was spending $30,000 on an anti virus server because our VP of Networking opened an attachment he shouldn’t have which ended up fragging his hard drive. As if it weren’t his fault.

From Yako Entertainment to Game Thoughts:

I moved on and began looking at starting my own company again. My first company had been called Yako Entertainment which I started in early 1998 selling computer gaming systems at about the time that it was blatantly obvious that Dell hardware really sucked. At Clearwire, every single day I was replacing some piece of hardware out of someone’s computer. Within a couple years, Dell systems got a fair bit better, low end hardware prices dropped dramatically and I decided it was time to get out of building computers. It wasn’t nearly as profitable anymore. It was getting difficult to convince Joe User that the computer he bought from me was far superior to the one he got from Dell at roughly the same price. Even worse was that my margins were decreasing, and I couldn’t keep up with Dell. I closed the company that year I think it was, and started Game Thoughts with my cousin in August of 2000.

One of the first things we did was purchase a software package called Bugaware. It was written with ASP, and was something that I knew we could have written on our own, but we felt our time would be best spent elsewhere. My quote is still on their testimonials page, nearly 6 years later.

As time went on, the gaming business we were running took more and more turns for the worse. I learned a great many things during that time about running a business, but the money just wasn’t coming in as fast as it was going out. Before I had started Game Thoughts, I had considered building a company writing business software, but I wanted to be able to leverage my forte which was web based programming and databases. At the time, I was having a really difficult time coming up with software that hadn’t been done before. Certainly I could have developed a bug tracking program, but that had been done before. What about web mail? Done. Forum software? That had been done too and in about 300 different programming languages. What else?

The more I thought about it, the more I realized that any software I could think of writing had already been done. It took me several more years before I realized one very important thing. Competition is a good thing. Not only is it a good thing, but it proves that there’s a market for that software.

It’s not hard to write software that’s never been done. How about a web page that checks a web site every 30 seconds to see if another web server is responding to requests? Certainly original, but I rather doubt there’s a market for it. I remember hearing a saying once that went something like this.

“The early bird gets the worm, but the second mouse gets the cheese.”

A lot of companies have very original ideas, but most go down in flames. Some of them simply don’t have a market, or their market disappears while they grow. Clearwire itself was a great example of a company whose market shriveled up before they even got started.

Initially, Clearwire charged nearly $2,000 for each installation and another $1,000/month for the Internet access at a synchronous 1.5Mbps. It turned out that the transmission rates really weren’t that fast and as they cut their installation and monthly charges due to numerous customer complaints, cable modems appeared on the scene, virtually wiping them out. I left the company in December of 2000 and less than 24 months later, the company practically self destructed. Everyone I knew who ever worked there had either left or been laid off. The entire executive management team was gone, the company was divided up, sold off in pieces, and life went on. So it goes.

The company is still around of course, and I find it somewhat entertaining that Craig McCaw claims to have founded the company in 2003. I think I probably still have a pay stub stating that I worked there in 1998, but I may have thrown that away last year, since my seven years of holding onto them are up. I guess “On the Internet, nobody knows you’re a dog.

A few more years of bouncing around, and I kept working on different web based software applications which I could never quite bring myself to finish. Web server analytics, forum software, bug tracking, project management, etc… With one exception that never panned out financially, nothing original or exciting ever came to mind. Then the thought came back to me again.

“The early bird gets the worm, but the second mouse gets the cheese.”

The biggest hurdle I found to finishing the applications I wrote was that I would look at them and say “There’s no way I would ever pay money for this.” I think that dealing with games was too harsh on my sensibilities. I’ve said this before, but games and business software are fundamentally different. When you’re writing a game, version 1.0 can’t suck. If it does, you’re sunk and there’s really no fixing it. But, business software is different. It’s ok if Version 1.0 isn’t that great. It’s ok if it doesn’t directly address the needs of the market you’re intending to enter. In fact, it’s better if it’s not even feature complete, so long as the design is extensible to meet different needs.

Software that is feature complete is a lot harder to make fundamental design changes to. It’s hard to get things right on the first try, and each time you try, it will get better. Every version will get progressively better, and with each version, come more customers. If you never had any to begin with, you get exponentially more customers. Since you’re building the product incrementally, if it is functional you can gradually move into the market that you really intend to go into.

With that thought firmly entrenched in my mind, I started writing Moon River Milestones… sort of. Truth be told, Moon River Milestones isn’t the first name I came up with. It’s not the second name either. It’s also not the first time I’ve written it, nor is it the second time I’ve written it.

A trip down Alzheimer lane:

I’ve changed my mind on so many things over the years, it’s hard to keep track of them. Let’s take a mild trip back into history. For company names I went through Global Forefront (registered, but abandoned it), Brainstorm Software(already taken) and Bitclinic Software as decent candidates before I settled on Moon River Software. A good friend of mine and I were sailing with our respective wives (his fiance at the time) north of Marblehead, MA and he brainstormed some ideas with me. Bitclinic Software was the primary choice at the time, but my wife had commented on how harsh the consonants sounded together and how difficult it was going to be to understand over the phone. The name Moon River Software eventually arose out of the fact that ‘Moon River’ was the song that my wife and I danced to on our wedding night. It started as a joke, but all four of us really liked it. My wife definitely liked it, and that’s how it came about. She does tease me every once in a while about the fact that the initials are ‘Mrs’, as if it belongs to her.

Shameless plug: Incidentally, she also designed the Moon River Software logo. She has a Master of Fine Arts in Graphic design from RIT which is where we met when we were both doing our graduate work. If you’re interested, she does freelance work for $50/hour billed through Moon River Software, and I can put you together. FYI, she specializes in print design, not web design.

I do acknowledge the gross similarity of the names ‘Moon River’ and ‘Fog Creek’ and will state that it is complete coincidence. I wish it weren’t so similar, but I still like the name we came up with and wouldn’t change it for anything. Every single person I speak with about consulting always remembers the name of my company because the managers I deal with are all in the age range where they remember the song.

Moon River Milestones wasn’t the first name of the software either. It used to be called ‘Total Project System’, as in TPS reports. I’m a big fan of the movie ‘Office Space‘ and thought it would be an amusing tribute. Having worked in some truly hellish environments, it only made sense and fit well with how bitter I have been at times about how most companies treat their employees. I’m willing to bet that most of you can relate from one job or another. I also called it ‘Project Commander’ or ‘Total Project Commander’ at one point, but I never really liked either name. ‘Project Management System’ was number one for about 5 minutes until I realized the implications of the acronym and trying to explain to prospective clients that PMS was a good thing.

Moon River Milestones grew on me after a while. I was pretty annoyed after I launched the software to find that there’s another software company out there that makes a product called Milestones. Thankfully, I had some legal advice that had previously noted that the fact milestones is a relatively common word would make it difficult to make any sort of legal claim to the name, and might open me up to legal threat if anyone else already held a legal claim to it. The solution was to affix the company name, which is why it is always referred to as ‘Moon River Milestones’ on the web site, never just ‘Milestones’. Also, the fact that their software is client based, not web based does tend to help. I’ve never seen in my web logs any traffic that probably should have gone to their site, and until today had forgotten they even existed.

I did a usability test of my web site after I first launched MRM and my test subject clicked everywhere except on the ‘Moon River Milestones’ link for the software. He pointed out that to him, the heading meant company milestones, not a software package. *sigh* The trials and tribulations of not having someone else to bounce ideas off of certainly makes things much more difficult. I suppose that’s why you always hear about partners who build great companies, never great companies with just one founder.

So, back to the story. With each of those names came new code, different design specs, and even different technologies. Truth be told, I wrote a system back in 1999 as well for use inside of Clearwire for our MIS department using *shudder* Perl again. I’ve written this software with Perl, ASP(two or three times), and C#.NET so by now you’d think I would know everything that I want it to do. I can truthfully say that I don’t.

I had never seriously considered using .NET until this iteration, and I must say I absolutely love it. It’s so much easier than working with classic ASP, which is an incredible pain when you’ve got tons of code you’re trying to reuse. It’s not portable like Perl, but even Perl had its problems, particularly with installation and setup (yea, I mean Bugzilla). I’m a big fan of IIS and SQL Server to begin with, so not being too portable doesn’t bother me. It narrows my target audience, which equates to fewer customers. If you continue reading, you’ll see when you find out who my target audience is why this isn’t going to matter.

The result of all of my coding efforts, designs, redesigns, recoding, and extensive use of the software is what you see now. The UI looks like FogBugz you say? Yea. I know. It wasn’t intended that way, it just turned out that way. I saw a lot of things in FogBugz that I liked, the layout particularly and the fact that my software had a lot of the same types of high level objects made differentiating it somewhat difficult. I saw a some things in Bugzilla, Bugaware, Elementool, Bug-Track, IssueView, ExtraView, MS Project, and probably half a dozen other pieces of software that I liked too. I took what I liked and tossed what I didn’t. In the end, that’s my work on the software. I certainly wouldn’t take credit for the UI layout though.

If I had to guess, I’d say that probably 90% of the features found in both MRM and FogBugz are found in 90% of all web based bug tracking applications or software which touches that aspect in one form or another. It’s not merely a coincidence, because it’s partly a function of the software. I’ll point out that SourceGear’s Vault looks and acts incredibly similar to Visual Source Safe in nearly every aspect. It also emulates every feature of CVS, but I suppose that’s ok though, because we know Eric and we like him.

The UI is the most noticeable likeness to FogBugz. If I changed the background to orange and move the summaries to the right hand side of the page, it probably wouldn’t have drawn nearly as much notice, although I could be wrong. I find it interesting, that I get bashed for making the UI of my product look like another product. Yet the example given which I supposedly ripped the name off of is a blatant rip off of Microsoft Project. That goes to show that people see what they want to see. The fact is that it’s the application that sells, not the UI. FogBugz sells well because it’s a great bug tracking tool. I expect that MRM will sell well because it’s a decent project management tool. Selling well has nothing to do with the UI, unless you’re selling a game, and of course they don’t let you return them after opening the box based on the pretty pictures.

I also saw a lot of things  in many of those software packages that I didn’t like and purposely left those out. In FogBugz, it was the idea of no required fields. Come on Joel. It’s bug tracking. On one hand, you state that every good bug report needs X, Y and Z. Yet, no fields are required in your own software? It seems a contradiction in terms. I do understand the necessity of getting people to use the system, but if your employee is refusing to use the software, then maybe you need different employees. I could easily argue either way on that little tidbit. I don’t have exceptionally strong feelings on the topic, but I made far too many mistakes when using MRM myself that I made some fields required so that it wouldn’t accidentally submit the page when I didn’t want it to.

There are some things that at times, I really wish I had left out. I never thought that implementing sub-projects was going to be such a nightmare. The problem is compounded by the fact that all of the subproject milestones and stakeholders can inherit from the parent project. It can get ugly. My first customer tells me that’s why he bought the software though. It was the only software he could find that supported sub projects. Having used sub projects myself, they certainly are useful, but it’s painful to work on the code for some of it, especially for the more complicated custom queries where nearly anything goes and tables are joined to themselves multiple times, but only in certain circumstances.

In terms of blatant borrowing, I really liked Joel’s idea of Features, Inquiries, and Bugs. But something that always bugged the hell out of me (no pun intended) was that for general project management in a small company, the three categories of FogBugz simply didn’t cut it. Where do I put “Install iMail on the web server”, or “Order a new hard drive for the file server”. It’s not a Bug. Not a Feature, maybe an Inquiry. <high nasally voice> Johnny, can you install this software? <end nasal> So I added in the concept of Tasks, which to date has proven to be an incredibly useful part of the software.

On the other end of the spectrum, BugAware allows you to create all of your Issue types and set them to anything you want. This too was something that I had seriously considered for weeks on end. A quick check of the demo shows Bug, Failure, Change, Addition, Create, Purchase, Install, and Request. Umm… is installing iMail a Change, and Addition, or an Install? Technically, it could be any of the three. I never liked that either to be honest. BugAware was far too configurable, and FogBugz not enough so. I wanted something that was reasonably in the middle. I tried making changes to my previous install of BugAware and it was a considerable mess. Just terrible to deal with. The only option was to reinstall completely and delete what I didn’t want before I even started. Eventually, I settled on a solution that fell between what I felt were the two extremes.

Will Joel add ‘Tasks’ to FogBugz?

My guess is probably not. It’s possible and I think that he should, but I don’t think he will. You see, that is a marketing question, not a programming question. FogBugz is bug tracking software. It’s intuitively obvious that it is meant for tracking bugs and it does so very well. Milestones is meant to help small groups of people finish internal and external projects which means that not all of them involve writing software. That’s why ‘Tasks’ are there.

My first paying client was an IT/MIS department, not a software shop. Coincidence? Hardly. “Development teams, IT departments, blah blah blah. Mike you’re an idiot. There isn’t any real difference!?” you say.

These two may sound like the same thing, and even seem like it on the surface, but they’re not. Not by a long shot. If you’ve ever worked in an IT department, you’d know the difference between IT/MIS departments and true software development teams. As a developer, you probably don’t have to deal with most of the issues that most ‘normal people’ in the company run into because if you’re anything like me, you want admin rights on your computer. No, in fact you demand admin rights on your machine.

But Nancy Finance doesn’t have admin permissions. Hell, she can’t even install the latest and greatest version of ‘Fancy Pants Photo Viewer‘ because she doesn’t have permissions. She can’t install the latest Office Service pack either. What does she do? She calls tech support, they write it down somewhere, and eventually they might get to it. Every IT department on the planet is incredibly overworked. There are so many things they have to do that they never have time to get to, or they forget to do, or just isn’t important enough, or they lose track of.

One company I worked at had a lag time of 3 weeks to set up an email account for a new user. THREE WEEKS!!! Now, I know Exchange Server can be a bit slow with a lot of users on it, but isn’t that excessive? Hell yes! It takes 2 minutes to do it, and either you or I could do it with the right permissions and zero knowledge of how to do it. What was the real problem? Their trouble ticket system was a nightmare to use. They had two developers working on it full time. Clearcase anyone? Project management software that requires two developers working on it full time is crazy. Don’t bother commenting to me on how great Clearcase is, because I really don’t care. I’ve never actually worked with it personally, and I know it’s incredibly complicated. That’s about the extent of my knowledge. The point is, that trouble ticket software doesn’t need to be anywhere near as complicated as something like Clearcase.

The root of theproblem:

Why does it take 3 weeks to get simple things done in an MIS department? There are a few reasons that I can think of.
#1) They are overworked. There are too many things for them to do, and not enough time in the day to do them. Their Blackberries are going off every 3 minutes because another user accidentally had the CAPS lock on and locked themselves out of their account so they need the admin to unlock it before they can do any work. This interrupts the person a million times a day. Translate Joel’s articles on interrupting programmers to any other person. Crank up the interruptions to every 3 minutes, and it’s even worse than just annoying. It’s downright dehabilitating.
#2) They don’t have a good system of keeping track of everything that needs to be done.
#3) Even if they did have a good system, unless it lets everyone know what’s going on, it doesn’t help much. You get four people each with the same account to unlock because the user got impatient and asked everyone he could find to unlock the account. (hint: Spiral bound notebooks don’t cut it. I should know, because I’ve tried.)
#4) Reprioritizing things is hard unless you can see everything that needs to be done on a more global scale.
#5) Reporting, reporting, reporting, reporting… Did I mention people need reports?

Running a small company is a lot more like running an IT shop than running a software development shop. Joel may be violently opposed to letting reports be run on FogBugz, but for an IT department outside of a Utopian office in New York they’re a necessity. The larger the company, the more important those reports are.

Need an example? A company I used to work at, one of the teams had a meeting every morning for on average anywhere from an hour to two hours. Five days a week, they lost an hour or more. Nearly a full day every week spent in this meeting talking about what was being done, how it was going, etc. My team never had a meeting. Every week, I dutifully took an hour and submitted a 4 page report that detailed the progress of my team, what was going to be done the following week, what didn’t get done that week, problems we ran into, etc. I would go for weeks, even months without having a meeting. Either we were incredibly unimportant, or those reports meant something. Wasting that one man hour every week save us three man hours minimum, perhaps as much as fifteen. And everyone knew what was going on every week.

Important items of note:

There are three important things to note about Moon River Milestones. First, is where it was. Here’s UI mockup that a graphic designer I was working with sent to me in the early stages of development. He sent me some CSS code that I used as well, but translating things from Photoshop to web software doesn’t always come out the way you want it to, so the final result isn’t exactly what he sent to me.

Second, is where the software is now. It is bug tracking for the most part and is being advertised as such. The primary user of MRM for the longest time was myself. Nobody else. I’m working with a marketing consultant who is helping me figure out how best I can proceed and bring it to bear on the IT real target market.

Third, is where it is going. Corporate strategy would tell me to keep my mouth shut about where it’s going, but I think I’ve made it painfully clear. Project management for small IT organizations, targeting companies with under 50-100 users is one of those fields where the software really just sucks. Do I have reports yet? No, not per se. The reports I have are called ‘One Click Filters’ which can organize all open issues for you with just one click of the mouse. A full on reporting system is planned for version 1.2, but that’s probably 4-6 months off. Are development teams a focus for me? No, not a main focus to be honest. Dev teams are so hyper-critical of the software packages they use it’s not even funny. “Hello Pot, this is the Kettle. You’re Black!”. Yea, I know I know. But at least I use my own software. Developers are fanatical about nearly everything. Tools, operating systems, favorite blogs, best item on ThinkGeek.com, you name it. Go to the Slashdot forums and say “Linux sucks”. You’ll see what I mean. IT departments on the other hand want their software to just work. It doesn’t need to be fancy. It just needs to do what they need it to do.

Version 1.1 of the software is just around the corner. Nearly all of the improvements in version 1.1 are based on things that have simply been bugging the hell out of me. Sorting, more columns on the main page, issue groupings, SMTP server settings, HTML/plaintext email, etc. Version 1.2 has a lineup of pretty sweet functionality that will make it a serious competitor in the IT market. I’ll be renaming ‘Issues’ to ‘Tickets’ to help conform to that market as well.

Conclusions:

Well, running things on your own is hard. Anyone who has ever tried running a business on their own probably has at least a little bit of sympathy for what I’m doing. Turning a profit on a business by yourself in only 3 months with some hefty software expenses is actually pretty difficult. I don’t know whether after reading this it will be more or less. Regardless, I think I’d like to use this as a learning experience though.

Lesson #1: When writing the first version of your software, do not, under any circumstances, look at your competitors. Don’t look for ideas, don’t look to see what features they do and don’t have. Just resist the temptation. The fact is, that when you see something good, it’s very difficult to get it out of your mind. Even if it isn’t good software, it will leave an impression in your mind, and you are more likely to follow that impression than your own good sense. How do I know this? Because the first two versions of the software I wrote were probably pretty close to being what BugAware was. I scrapped them both for that reason. I certainly wasn’t basing my code off of theirs, but I didn’t want to be accused of any impropriety so I didn’t continue. In the case of MRM, I suppose that I felt that since I didn’t have the source code and had never seen it, then it wouldn’t matter. I think that was a mistaken assumption. Finding a design partner would probably have helped.

Lesson #2: Get a partner. Objectivity is hard to come by. Unfortunately, so are good partners which is why that to date, I don’t have one. Chances are a partner would have taken one look at it and said “No, this is too close to that. We need to change a few more things”, which would have avoided all of this controversy.

Lesson #3: Spend more time on your software than worrying about what other people think. The fact is, I didn’t copy someone else’s code. Deep down, I know that, and anyone who used the software once would know that immediately. But the court of public opinion is a harsh court, and everyone has an executioners axe.

Lesson #4: Give credit where credit is due, even if it’s only a vague reference. I wrote an article a little while back citing my goals for 2006. I spoke of McDonalds and mentioned it’s the same burger whether you get it on the New York State Thruway, or in Trinidad. To explain a bit, I grew up in upstate New York, and ate fast food on the Thruway quite often. I went to Trinidad one year with a bunch of friends, and after nearly a week, I needed some ‘normal food’. There was a McDonalds on Trinidad and knowing it would taste the same as what I was used to, I got two cheeseburgers, large fries and a Coke. It helped soothe the sickening feelings in my stomach that had been developing over the past few days of eating “Shark-n-Bake”(their words, not mine), goat something or other, and lots of stuff with curry. The McDonalds menu was different, as I stated, but the food tasted the same. This comment was based on personal experience, but I really should have given credit there to Joel for the original article, since that also came to mind when I was writing it. I’ve done so with a link back to his article. The fact is, that it wasn’t an entirely coincidental reference.

Lesson #5: Not all critics are right. One poster on Joel’s forums commented on a piracy article that I wrote, insinuating that I somehow am condoning piracy which is not correct. He’s apparently got the impression that I lurk in the forums condoning that action on occasion, which is also incorrect. I honestly don’t think I’ve  posted to Joel’s discussion forums in probably more than a year, possibly two or three. I couldn’t say for sure, because I simply don’t remember when it was. I simply don’t have the time to get involved in most forum groups anymore. On the other hand, piracy is a serious problem, and my article points out some of the problems with hunting down those people. That article was based on a personal experience trying to track down a Russian cracker who was posting cracked games on eDonkey that I was distributing at the time.

Lesson #6: Sort the wheat from the chaff. In every group, there is what I have come to know as the 10% weasel factor. There are obviously other terms, but that’s the most politically correct one I’ve ever heard. Basically, it says that in any group, there are 10% weasels, 10% leaders, and 80% sheep. As a leader, your job is to convince the sheep to ignore the weasels so that you can get good things accomplished. The weasels generally try to prevent anything from getting done and are mostly destructive in every way. I’ve received some pretty nasty emails over the past 12 hours or so, which is pretty sad since nobody has even heard the other side of the story. But of course, the weasels don’t care. They’re there to stir up trouble, thrive on controversy, and are bored otherwise. For those of you who didn’t grow up on farms, sorting the wheat from the chaff means to take the good and ignore the bad.

Lesson #7: Figure out the root of the problem. I certainly hope that my comment about Eric and Vault doesn’t piss him off. I think he’s a brilliant guy, an incredible writer, and an even more incredible teacher. I’ve certainly learned a lot from reading what he has to say over the past few years. But the fact is, that the entire Joel on Software thread discussing MRM is currently riddled with a level of hypocrisy that I haven’t seen since I turned on the news last weekend. As moderator of this particular thread, I would think people know who he is and are familiar with the stuff he has done. You should know that he made aconscious effort to copy Microsoft’s product. Yet, here I am being crucified for something far less serious, while he has been applauded both publicly and privately for what he made a conscious effort to do. Is there something that I’m missing? I’ll quote part of his article and link to it for those of you who haven’t read it.

Painless transition
As far as we know, Vault is the only version control system designed specifically to replace SourceSafe. In every way possible, Vault presents a familiar interface with familiar terminology. Every major SourceSafe feature is supported, including things like Share and Pin. Our import tool will move your SourceSafe database into a Vault repository, including all historical information”

I’m certainly not perfect, but I’m definately willing to make an effort to correct anything that may be seen as personal transgressions and flaws in the things that I have done. I would think that this is evident above in #4 where I linked back to one of Joel’s articles. And if I missed any others, feel free to politely point them out. I will correct them as quickly as I am able.

But here’s what I’m really looking for. I’d really like for someone to in a coherently polite and honest fashion explain to me where I have gone wrong relative to Eric’s “Painless transition” for Vault, because this is the very sort of attitude and treatment that drives hard working developers away from communities rather than towards them. I can only come up with two things. 1) I should have reverse engineered FogBugz and marketed MRM as a replacement for it. From there, could I have done anything I wanted. or 2) If it were a Microsoft product, it would have been ok for me to do it. I simply don’t understand where I went wrong relative to Vault’s position statement of painless transition for Visual SourceSafe. Or are the weasels having a good laugh at my expense and this entire article was for naught?

The impression that I have is that JoS readers are pissed because they don’t know who I am, or much about the story behind Moon River Software. I haven’t talked a lot about my past, my background, or my history on my website and not knowing bothers the readers. I don’t think it’s really about a similar UI either. I think a lot of it stems from people thinking that I in some way was pirating FogBugz, rebranding and reselling it, and if that’s the case, I can understand because I’d be pissed too. But that’s not the case, which should have been evident from the fact that I actually purchased CityDesk, but not FogBugz. So, what is the real issue here?

If I missed anything, or you don’t feel like I covered something, please let me know, and I’ll try to respond.

Share/Save/Bookmark

The end of Milestones v1.1 is in sight!

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

There’s only five issues left to deal with in order to get Milestones v1.1 functionally complete. After that comes final testing, and making sure that the installer works properly for both upgrades and new installations. Each of them appears to be no more than a few hours worth of work, but since we deal in software, you know that averages out to about a day to finish each one.

The installer process will be the worst one to deal with I think. For Milestones, I made a concentrated effort to make sure that the installer just works. No hassles, no fuss. There’s nothing worse that downloading software and having installation problems. I think of it like registration or license code problems. It’s not even a real part of the application, but without it you’re ship is sunk. It’s really a pet peeve of mine. I’ve completely skipped over software that didn’t install correctly the first time every time. That’s one of my major beefs with Oracle.

If it’s a complicated install process, you would be wise to test it as thoroughly as you can before you let it out the door. After all, the installation is the first part of your application that people are going to see. And if the installation fails, not only do you look terrible, but you have zero chance at the user making an educated guess about whether it solves his problem or not. In fact, it’s even worse because the only thing he knows is that you product won’t install.

Is it a good product? Who knows? Will it solve his needs? Who cares. If it won’t install, it won’t run, therefore your problem cannot be solved with that software, unless of course you were looking for 53Mb of NOOP statements and an error.

If a company can’t take the time to make sure the installer works properly, what makes you think they took the time to do sufficient testing on the rest of the product? Interesting question, don’t you think?

Share/Save/Bookmark

Strategy Letter #1: How to Grow Fast

Posted in All Articles, Business on February 1st, 2006 by Mike Taber – Be the first to comment

Tom Hanks played a little boy in the movie ‘Big’ who simply wished to be big and woke up the next morning bigger than he had imagined. Of course, that was only a movie and no matter what the storybooks say, you can’t grow big overnight whether it’s you personally or your business… or can you?

Recently, I found a post by a blogger that I regularly read named Rob Walling. I mention his site every once in a while, and this post caught my eye. To summarize in case you’re too lazy to follow the link (and I know that some of you are), Rob purchased forum software from someone about a year or so ago and hadn’t had any time to devote to enhancing it. While it was drawing money and web site traffic, it wasn’t something that he wanted to continue to support or invest any further time into. Thus, he had decided to sell it to the highest bidder.

Now, I’ve seen things like this happen before. Eric Sink sold his ‘Winnable Solitaire’ program that he wrote in his spare time as an experiment. I believe that his total gain was perhaps $1,500, which isn’t much, but it’s more than nothing. Another software package called ‘BrilliantPhoto’ was sold directly on eBay. Actually, it was put on eBay probably to draw attention, and then was sold in a closed doors session shortly thereafter.

In both of these cases, the complete source code and rights to everything were (probably) sold. I say probably because those were the initial terms offered, and I rather doubt that once they were offered, they would have been retracted. So, Rob was selling ChitChat.net outright to the highest bidder. Now, I gave this some thought before I even emailed Rob about it. My first thought was, is this even a viable product?

It seemed like it was. Rob had apparently been selling it for nearly a year with almost no promotion and making reasonably decent money from it. The fact that no enhancements have been done in a year and people are still purchasing it meant that it was filling a certain need. The question was, which need is that? So, I delved into it a bit. It turns out that there are only a handful of forum software suites written in C#.NET for sale that fall in the sub $500 price range, include the source code, use SQL Server as the back end, and run only on Windows. In-ter-est-ing…

Now some of you are probably thinking, “Mike, you’re an idiot. You’ll never make your money back and you’re just wasting your time. There’s a ton of free alternatives out there. Why would someone buy that from you?” Isn’t Linux free too? And they have a stranglehold monopoly on the OS market, right? They don’t? Hmm. Let’s stay on this train for just a bit longer then, shall we?

I decided about a month ago where I wanted to take Moon River this year, and it certainly didn’t include buying forum software to enhance my product line. But it wasn’t too far off either. In fact, it fit eerily well into my plans. It could compliment my existing product and serve as an integrated piece of some of my other upcoming products. When most companies sell out, they sell for millions of dollars, if not tens of millions. When you create a startup company and you’re looking for venture capital investors, you have to set a valuation on your company that often seems absolutely absurd. How in the hell could a piece of software that barely works, isn’t out of beta and has no customers be worth anything? Ever use Google? I have no idea what their initial valuation was, but their first investor gave Sergi Brin and Larry Page a check for $100,000 just to get them started.

The value of a company, especially a startup, isn’t just the value of the current product and the few thousand lines of source code that it consists of. The value of a company is based on the implementation of an idea and the value of all the future work that the employees will do. - (Paraphrased from Paul Graham)

So, did this product have value? It certainly seemed to. There was a viable market for it, with competition in lots of different areas. Sales were coming in, so it was definitely a product that could be moved. The lack of effort put forth in selling or enhancing the software seemed as if it were the primary downside to the software. But what about the code? Was it decent? Was it a spaghetti mess that I’d take one look at and never touch again?

I did the only thing I could do. I asked Rob if I could see a copy of the source code. I figured he was selling source code licenses, so it wasn’t a particularly big stretch to ask to see a copy before I made an offer on it. Time was of the essence though, since he had said he would only accept offers for a few weeks, and would accept the first offer over $5,500 immediately.

Rob apparently saw the value in allowing me to see the source code. To be blunt about it, I certainly would not have made an offer had he not. I wasn’t going to spend $99 to get a source code license just to see that it wasn’t worth my time. I received the source code with a request to delete it if I were not the winning bidder, which I readily agreed to.

After looking over the code for a couple of hours, I was actually more impressed with it than I had been by merely looking at the database layout. You see, I’m a bit of a database buff, and just looking at the database design for a product can generally tell you how well things are put together under the hood. There weren’t any foreign keys between the tables which worried me a bit. But after looking at the code, I could tell that the original author took a lot of care in putting things together in a manner that made it easy to follow.

I had the code built, compiled and running on my machine in less than half an hour, and that included a lot of fussing with the solution file because of the revision control stuff buried in it. All in all, it seemed pretty good. A week or so later, I received word from Rob that he was accepting final bids until Friday and he would make a decision over the weekend. I made my bid, waited a few days, and was informed that my takeover bid had been successful. Less than six months in business and Moon River Software had its first acquisition. It includes nothing more than technology transfers and domain names. No employees to take care of, no health plans or 401k plans to transition, nothing complicated like that at all.

So what really led to this decision, and was it really a good idea? I suppose that only time will tell for sure whether or not it was a good idea. Personally I think it was a great idea. My marketing consultant asked me some rather pointed questions, acknowledging that he had some concerns about how well it fit into the future of Moon River and the goals that he and I discussed. I can share with what led up to this decision though.

1. The right technologies.

Moon River Software is doing a lot of work with C#.net right now. We acknowledge that could change in the future, but that’s where we are right now and that’s where we’re going to be for the foreseeable future. It also happens to be the direction which we’re moving deeper and deeper into. Were this software written in PHP, python, lisp, perl, or even VB.net, I don’t think this would have happened. The overhead to convert the underlying technology would have been too much to bear.

SQL Server is currently our database of choice. While I’ve never seen hard facts to support this, my inclination is that people who like php, mySQL, LAMP, LIMP, <insert some other acronym of technologies here> have chosen those technologies in part due to the fact that they’re free. I like free stuff too, but I can’t feed my family if people don’t buy my software. I feel that we’re better off choosing a back end database that lends credence to people who like to pay for software.

2. The right timeframe

Were this deal to come along 2 months ago, I simply wouldn’t have been able to afford it. Only in the past 2 months have things picked up enough for Moon River to be able to afford to purchase the rights to the software. Starting off as a consulting shop has definitely helped give our income a jump start, but as a consulting shop, the actual cash doesn’t come for several weeks after the billing statements go out. In some cases, not for nearly 45 days. Some consultants wait even longer than that to see their checks.

Even if I had the money two months ago, it still would have been a difficult decision because Milestones development was in full swing. Had I lifted my head, version 1.0.1 would not have gone out the door on New Years Eve.

3. The right price

According to Rob, the software had income levels of around $2,300 for the last 12 months. When most companies do acquisitions, they are done for anywhere from 8-20 times revenue. It certainly wasn’t worth $16k to me for that software, given what the development time to create it from scratch would have been. Even at $6,000, I rationalized it as me paying about $20/hour for 300 hours worth of work. That’s nearly 2 full months at 40 hours per week. Not a bad deal overall.

4. A complimentary niche market

ChitChat.net fits into a niche market that overlaps that of Moon River Milestones quite nicely. Both are web based pieces of software written in the same language, targeting the same platforms, and using the same databases. It’s hard to sell someone a SQL Server product when they only have Postgres installed. But if they have SQL Server, IIS and Windows to install Moon River Milestones, they can just as easily reuse that software and hardware for ChitChat.net, or vice versa.

5. A competitive product

The fact that ChitChat.net has been consistently selling at a minimal level with virtually no marketing effort lends credibility to it becoming a heavy player in the world of C#, IIS and SQL Server. The fact of the matter is that little time has been devoted to marketing or development. It’s been given very little direction and has essentially floundered, unable to find a clear path towards success in the world of .net forums dominated recently by Community Server and InstantForum.NET. It just needs a vision, which I think I have.

I spent a lot of time thinking about this over the course of more than a week. ChitChat.net is definitely a product I felt was a worthwhile investment for all of the above reasons and more. It immediately triples the number of products we have to sell because the deal included the SPROC builder, which I haven’t even talked about at all, reason being that wasn’t a part of the sale that interested me. And that’s one way to get bigger fast. Buy the product outright. It’s certainly not for everyone, and you need to have the money to do it, but it can be a worthwhile investment if you have all of your ducks in a row. A word of caution though. Don’t do something like this for the sake of expanding. Do it because you have a plan in mind that you want to execute. The previously mentioned ‘Winnable Solitaire’ was sold to an individual who already owned a web site selling a freecell game. For him, it was a great complimentary product. For me, it would have been a waste of money.

For the time being, you’re not going to see much change because most of the real work will be done behind the scenes. It will appear on the Moon River Software web site in the near future, and you’ll see more ties between the clickcess.com web site and the main MRS web site. Right now I’m neck deep in contract work for a client. Moon River Milestones v1.1.0 is nearing completion, and our next product code namedAurora is being written. If you don’t see anything right away, don’t fret. I’ll post more updates as work gets underway.

Share/Save/Bookmark