Later this week I’ll start the process of closing my start-up, aDeVIX Software. After months of planning and development, the decision has finally been made to call it a day. It was a great idea, but time and money conspired against us, with great effect.

We had a great product in mind, just not the resources to make it happen. I do believe that it would have been quite a success, but it takes a fair bit of time, and even more money to launch a commercial product aimed at mid-size businesses. It’s not a simple thing to sell software costing more than $10,000 per install; and being a company with no reputation, it’s almost impossible.

We planned the design, the marketing, the budget (even allowing for snacks & drinks), covered every detail, but when you don’t have the time to write code, or the money to pay people to write it for you; no amount of planning will help. We then delayed, then came up with smaller, simpler products, then scrapped all that and went back to the original idea.

Months of work, thousands of dollars in various expenses, and not a single dime as income; much effort, no reward. Many thousand lines of code, a few websites, countless meetings, and enough notes to account for the clearing of a small forest; but no money, no assets of value, nothing. It’s a bit painful to think about all the effort, and see that it was all for not.

It’s certainly possible to make an ISV work, it’s just a matter of being honest with yourself. Can you afford the expenses? Do you have the time? Will you be able to support the product yourself until it brings in enough money to hire people?

In some ways though, I’m happy that this is done, as it now leaves me free of any potential conflict of interest when it comes to pursuing future opportunities.

I love what I do, and I work with a great team. While it’s still far from perfect; I can say that I do love my job. For the last couple weeks though, I’ve had to remind myself of this several times. I’m sure we’ve all done it, in this industry it’s hard to avoid. You read an email or receive a phone call and repeat the mantra “I love my job, I love my job, I love my job.”

Unreasonable clients, managers that just don’t understand; there are so many reasons, so many triggers. While reciting this mantra often invokes laughter from those nearby, some thought should be given anytime it’s used. More often than not, used as a joke, but a joke masking true problems.

Some issues are unavoidable, some no amount a planning or preparation will help with; for those I can offer no advice. For those, even a perfect environment won’t help. It’s the others I care about, those issues that shouldn’t be, the deadlines that should never have been set, and those whose sole cause is lack of planning or forethought. Those are the ones that tire me; those are the ones I hate.

When I run into one of these situations, it makes me wish this was closer to reality than a dream of how we want things to be. However, why shouldn’t it be reality? Why do we allow this to happen time and time again?

Wait, read that last sentence again. Why do we allow, why do we allow? Yes, as developers we allow this to happen, and often encourage it. Late nights, working weekends, 90-hour weeks. Those could all be prevented, and could be reduced significantly should we stand up. If we do not take a stand, we encourage those that push us too far by doing just what they ask. Why should they stop if they can get a single developer to do the work of two?

A Solution?

So, what are we to do? Taking a page from Rob, here is my modest proposal. A few simple rules for both developers and managers to keep in mind. While rules such as these can never be enforced, keeping these things in mind could make life more pleasant for everybody.

Managers…

• shall keep requests for after hours work to a minimum. While there are “crunch times” on occasion, these should be minimal.
• shall seek input from at least one developer before estimating a project. An estimate should not be created without consulting those that will be working on it, as they should have the most realistic idea of how long it will take to implement.
• shall not ask developers to implement a hack or kludgey solution to meet an unreasonable deadline or request; especially if it will compromise stability or maintainability.
• shall understand that developers are often passionate about their work, and the quality of the software they produce. Asking a professional to implement a solution based on a bad design, or inferior technologies will often be viewed as an insult, especially when this is done to meet an unreasonable goal.
• shall shield developers from unnecessary distractions and meetings. Distractions can destroy productivity.
• shall not ask developers to do the job of a Support technician. Tasks such as installing or configuring third-party software should not be given to a developer.
• shall filter all requests and put policies in place to ensure that requests do not go directly to a developer.
• shall give developers the freedom and opportunity to test different development methodologies when the schedule allows.

Developers…

• shall make every reasonable effort to complete a task, including working long hours (so long as the hours and frequency are reasonable).
• shall not complain about boring or undesirable tasks.
• shall alert management when an issue arises that may impact a deadline, as soon as possible.
• shall build the best software they are able to.
• shall provide accurate estimates when asked.
• shall be available as much as possible should an emergency arise.
• shall not over-build, or over architect just for the sake of doing so.
• shall try to understand the pressures and forces at play when communicating with management.
• shall make an effort to improve development methods and processes.

If you agree with this last, take it to your manager and talk about it; if not, build your own and talk about it. Either way, the idea is to talk about the issues and try to find ways to get everybody on the same page. If we make no effort to improve things, then we are just as much a part of the problem as anyone else.

If you don’t like things, complain; but complaining to a friend or co-worker won’t help, you need to let management know that there are problems and that you have some ideas to fix them.

I’ve been a fan of Patrick’s blog for some time now, and one of his recent articles, Things You Shouldn’t Worry About, really shines. While I can’t agree with everything, most of the points really make sense. If you run an ISV, or are thinking about starting one, I highly recommend that you read this, it’s well worth it.

Developers have jobs for the money, right? If you want a developer to work hard, give them more money, right? Wrong. For many developers, money has little effect on motivation.

Being an odd creature anyhow, developers are a bit different in that the things most people seek in a job means little to most developers. A developer is motivated by a completely different set of factors, and I believe I've ran across a great definition of the things that really matter.

Rob Walling offers great insight in "Nine Things Developers Want More Than Money" - this is a great read, and I recommend it highly for both those that write code, and those that manage those that write code. For that matter, I highly recommend this for everybody, read it.

I just ran across an announcement for a new Microsoft product, Office Accounting 2007 Express. This is a free, and surprisingly full featured accounting package aimed at small businesses. If you run a business, or plan on starting one, this looks like a great addition to your tech-toolkit. I'll post more on this again once I have time to review it more thoroughly.

For those looking to get into the startup/ISV scene, Paul Graham's latest work is a great read. The 18 Mistakes that Kill Startups takes an interesting look at some of the larger issues to avoid while forming a new company. Personally, I'd call this one a must read.