Joel on Software readers up in arms – A view from the other side of the fence
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
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.
