Fog Creek Software
Discussion Board

Financial Realities

Just wondering what the general attitude to this problem is on this forum.
I am a developer in a small development firm. We write reasonably specialised software. Since joining I have managed to turn the product into an off the shelf package.
My boss (who also doubles as sales manager) insists on selling the software as a customised solution, and when prospective buyers ask about particular features that the software doesn't have, he assures them that for a minimal fee we can add it. Of cause the buyers are not interested in paying for the job to be done properly (ie properly specked out, written in a way that solves the problem for all users, and appropriately tested).
This means that we are made to do quick "hacks" that aren't properly tested and only solve the problem for that specific user. This development cycle has been going on for 18 months now, and I had a huge argument last week with him and his answer was that the financial realities were such that this had to be the way. My counter agument was along the lines that we should do things properly or not at all. I believe that the way forward is to pro-actively develop the software in the back-ground adding the features that customers most want, sell the product as is but with a list of features that will be in the next upgrade, and if this means loosing a customer here or there because we don't have some obscure feature then so be it.
I think the problem stems from the fact that neither my boss nor the MD are developers, and know very little about the development cycle. I am the most experienced developer there, and I feel as though I have little if no sway in the development cycle.
Short of leaving, what should I do?

Monday, August 18, 2003

While I agree that you should do more than hack solutions together, I can understand your manager's perspective.  Clients may not be willing to pay for and wait for the best solution to be implemented.

However, you only sell software if it meets needs.  Is it possible you could compile a list of features added for individual clients, identify needs, rank them by appeal (how many times a feature or feature set has been requested) and cost to implement fully.  Present this to your manager as a hopper style project.  A development team in its downtime (not implementing custom solutions (hacks)) could draw the next item in the hopper and spec it out and implement it "correctly".

That way you satisfy both needs by enhancing the product after the client is satisfied (as its beyond their scope anyway), but add value to the product in the future by enhancing the core package properly.

Monday, August 18, 2003

This type of situation turns into a maintenance nightmare.  After you add dozens of one off hacks for each client.  Do you branch the code base for each client? 

Monday, August 18, 2003

Are you the only one that wants a packaged product? Sounds like this business is a consulting model and not a software company. If everybody is working on the former, and only you are working on the latter - I can see where there might be conflict. If the people in charge want to run a company in a particular way for financial reasons, that is their prerogative. Since you obviously feel passionate about this, present too them how doing it your way will somehow save them money or bring in more customers. Think of it as a business proposal. If they reject it, there is nothing wrong with asking why, but don't forget, they run the company. Good luck!

Monday, August 18, 2003

Bella, this is exactly what I've been trying to get my manager to understand. At this point we don't branch the code, I couldn't think of a worse nightmare than having 30-40 different branched versions of the code, and having to track who has what.
Currently I believe the software nicely satisfies the 80-20 rule. The software satisfies 80% of clients needs, and the other 20% are the problems that the hacks are required for. It is a hard lesson for a salesperson to learn that you cannot satisfy 100% of clients needs and still be able to sell your software at a price that is acceptable to the mass market.
Thanks Lou, I will endeavour to write such a list, but I will still insist on maintaining my firm opposition to the "hack and go" development cycle that has been the norm for the past 18 months within my company.

Monday, August 18, 2003

m, I think you have hit the nail on the head. They traditionally have been a consulting firm, and the software side has evolved out of that, and so this is the way they understand business, you do work, you get paid by the hour. However, they reality is that the market they have gone into is far more applicable to the off-the-shelf software model, which I know is what they really want to get into. It's just hard to get them to see beyond the quick cash in the hand mentality.
Software consulting costs far too much for our average customer, which is why my attitude is sell the software as is, and let the customers who won't buy the software if it doesn't have built in support for widget info go and pay tens of thousands of dollars to a consulting firm who will do them a solution from the ground up.

Monday, August 18, 2003

sjb I feel your pain, I was in exactly the same position.
An ex-co worker and I were just having a chuckle at how similar the companies sound.

The basic problem in my case is that the company weren't sure where to position themselves. We flip flopped between a "Shrinkwrapped Software" company and a Consultancy.... sometimes a few times in the one day.

It got to the point where I had multiple forks of the code and a total maintainance nightmare because I believed the CEO everytime he said "This is the last time this will happen" or "it's a one off".

What needed to happen was for me to negotiate some downtime to clean everything up and re-architect bits of our software to meet all the requirements but a combination of burnout and naivety stopped me from fighting for it.

In my case, I left, as did the other developer a few weeks later. But there were a lot of other factors involved there (I'm sure we ALL have our war stories).

In hindsight, it could have been fixed... but I'm much happier now for moving on.

Monday, August 18, 2003

"My boss (who also doubles as sales manager)..."

Sales people never want to say no to a sale.

As someone else already mentioned you are going to have to come with a strong business presentation before you try again to argue your case with your manager.

If leaving the company is not an option for you then you need to start thinking about how you can make the present situation more tolerable for you when/if your manager rejects your ideas.

Good luck and let us know how things turn out.

One Programmer's Opinion
Tuesday, August 19, 2003

Domain: thanks for your solidarity, I agree that "down time" is the key, but also the whole burn out thing is an issue as well.

One Programmer's Opinion: I guess leaving is always an option, and I occasionally browse through job adds. However, I don't see it as the only option. Like you said, I have to try to make the present situation more tolerable. I remember when I first read the Joel test (shaking my head thinking I wish), and ranked our company at about 3 or 4 out of 12. For some things, such as Daily builds and functional specs I have employed joels slowly slowly catchy monkey style approach, (ie. do it yourself and hope that it catches on), but I don't think this problem is as easy to solve.
The advise given by this forum has given me a few ideas about how to present my case. Only time will tell I guess.
Thanky you.

Tuesday, August 19, 2003


I feel your pain. I was working at one of these niche software shops before also. We also did per client customizations.

In our case there was at times very little value added by the customizations; mainly we were moving edit boxes around and changing labels in the data collection forms.

In my experience the clients failed to realise that the software gave a certain workflow, and by changing the application around without knowing how the different parts interacted they broke the workflow of the application, leaving it if not useless, but less useful.

With the application being less useful it is concieved as a secondary source of information. Unless you understand how the application works to the fullest, you will never get first class data quality. Unless you have first class quality of the data the reports are not considered useful, because they are incomplete and what have you.

When you talk to MDs you more often than not hear a discussion along the lines of "We do things no one else does; I have developed my own way of doing things."

This is not true for the most part, the most differences is in the terminology used, and also some people prefer vertical as opposed to horizontal data entry or some such. They can not possibly have it any other way. When you tell them that they do pretty much the same thing that everybody else they get offended, because who are you to say anything, you are not an MD.

Unless the clients realize they have to change their current workflow instead of changing your software product to fit their current workflow in the clinic you will never get away from doing customizations.

Maybe what you need to do is change the sales effort to sell an entire workflow; so the people realizes that it takes changes on their part in order to benefit from the productivity gains your software offers. I believe that if you manage to sell this, instead of individual obscure features, then you may be able to sell the software as off-the-shelf, and have time to develop the next version properly.

Tuesday, August 19, 2003

I know where it will lead (as probably do countless other people on this forum).

Essentially the name of the game is 'bums on seats'.  Promise customer everything.  Spend anything from 6 months to years implementing the solution.  Every time there is a problem then wheel in the salesmen and the top consultant to smooth everything over.  Programmer's will effectively hack bespoke code to death on each client site.  Implementations last anything from six months to years.  Company makes money because it is charging by the hour.  This effectively means that there is a disincentive to be more efficient.

The company makes money by maximizing the differential between each consultant/programmers wages and the amount they change each customer for the consultant.

Essentially the whole thing is basically a ponzi scheme.  They will end up employing the cheapest staff they can.

A sign that the game is up is when you hear rumours that the company is about to be sold and
guess who the majority shareholder is.

Leave, if you get a better offer.

Tuesday, August 19, 2003

Hmmm, no.  Its more like as others have said this is a consultancy business not a packaged software business and its extremely difficult to mix those together.

Witness burned fingers.

For small companies it becomes a habit not to turn work down, not out of any sense of greed but more out of a sense of insecurity as to whether an income stream is going to dry up or not.

Its frequently the sigh of consulting software companies to imagine some niche solution for one client is going to be generally practical as a shrink wrapped product and they imagine that as 'all' the development costs have been eaten by the client its an almost purely profit producing process.

Sometimes it works, but when it does its most often a very restricted niche where competition is slight. 

But the ambition to turn into a SAP or Siebel kind of company lingers.

Simon Lucy
Tuesday, August 19, 2003

I hear your pain, we have the same situation. We've found it's best to just keep everything in the same code branch, so we have bunches of if and switch statements based on customer ID. Sometimes we'll split if two deliveries are due close together, but then afterward we merge ASAP.

We have less than 20 big customers though so I guess it could be worse -- might depend on how many you're talking about.

We also strive to keep pulling apart the core product (as untouchable DLL's and base classes) from what could possibly be customer-specific (e.g GUIs and database tables) and taking an n-tier approach to new changes has helped with that. But evolution is incremental, so as new customer work comes in you have to add in extra time to your estimates (as much as you can get away with) to continue the migration to your newer core + customer-specific design.

We also add a "maintenance and support" fee to our prices, which funds post-delivery continued development that mostly means removing the really bad hacks and merging the good new things into the core.

It's always a continuum between a one-day hack solution and some robust 30-day data-driven implementation so you have to find a balance with your bosses. With us we usually end up doing the one-week solution, but definitely don't give into the one-day solution and point out to your management your costs will be triple or worse for subsequent changes. That's what we've found with one of our other products that was completely hacked, it took 3 times as long to add a new feature like a new field in a dialog box than it did with our product we were constantly refactoring....

Tuesday, August 19, 2003

Allow for plugins and hire one or two people to develop and customize them. They are billable and will have plenty of work to do. Once a feature/plugin is requested by a reasonable number of customers add it to the main code branch.

19th floor
Tuesday, August 19, 2003

All of this sounds very familiar.  I worked for a company who actually had a rather decent framework for adding user customizations in a way that didn't break the workflow (most of the custom work centered around reading different data formats, interpreting fields in a particular way, etc) or make the code unmanageable, but the customization had to be done by us on a billable basis.  (The software cost five figures for a license, and was more or less useless without a few thousand more in custom modules and support contracts.)  I was hired as a developer, but customization wound up being about a 3/4-time job, which left no time for further development.

My dream was to polish up the customization logic so that it was user-configurable -- which would've been great for me as it'd let me do more complex development tasks, and I had a feeling that combined with better marketing, we'd sell a lot more copies, but it was perceived as threatening the revenue stream.  I no longer work there, and they have a full-time staff person who spends (surprise surprise) about 3/4 time doing the same stuff I used to at a lower salary (not a developer, but knows enough VBA to do the job).  (Oh, and the app?  Still running on its original platform:  Access 97.  Yeah, you read that right.)

You may be able to argue your case better than I did, but it's going to be very very difficult.  Going from consulting to shrinkwrap is a risk.  It's possible that making the software require less (billable) support and maintenance (S&M) on your part would ultimately increase the company's revenues, but on the other hand, the market you're in may not be big enough to justify it.

Sam Livingston-Gray
Tuesday, August 19, 2003

As long as you aren't selling along side your manager, you'll never get to sell those perfectly good points. It's a rare day that a happy programmer in most mid- or small- size companies should sit in an office and not do a cent of selling. Customers don't want anything that's not sold to them. If you don't get a chance to find out what the customer really wants and never find out how to turn that into something you can sell you'll never get the politics changed in your favor.

Li-fan Chen
Tuesday, August 19, 2003

It sounds like you have a horizontal market for your software so I would treat it as commerical software for maintainability and the "custom solutions" become optional features.

Tuesday, August 19, 2003

Do not publish a list of features that will be in the next release. That will kill sales. All of your customers will wait for the next big thing, then the next, and so on.

Tuesday, August 19, 2003

I disagree: publishing features from the next release is a good thing, unless you have a release every 3 months. With a release every year or so, the list of new features will keep your customers hooked.

19th floor
Tuesday, August 19, 2003

I'll add to your pain.  I proposed what I thought was a really useful *product* to our non-technical upper management.  I was approved to do a demo, but not actually build the entire product.  The problem is the management wanted a paying customer in hand.  This is a horrible way to develop products in my opinion, but we are small and tend to be conservative. 

I can understand why management wants to do this, but they don't understand how much pressure that puts on engineering.  We are profitable enough that we could afford to do the engineering up front, so the financing isn't the core issue.

The second problem is the solution is technical enough that I don't think our sales people can do it justice when they present the idea.  It is one of those, "wow we could do that?"  that a customer would never come up with themselves.

The whole episode has made me question my commitment to the company.  I've decided instead of giving 120% to my employeer, I give the 75% everyone else does, and go home and work on my own projects.  This had made me feel much better.  I consider it like I am funding a start-up by the consulting for my employeer. 

I try to take as much as possible from the work I do at the office, as I have some great resources at my disposal, and then I go home and build exactly what I want.  This slight change of perspective has made me feel much better, since in the end I own my work. 

I am also single and have a great home office setup so I realize this might not work for everyone, but it has worked for me. 

I'd tell you but then I'd have to kill you
Tuesday, August 19, 2003

Let me assure everyone, the product we are trying to sell and the market we are trying to sell it to is definately suited to the shrinkwrap style. The small businesses that make up the bulk of our customers find it hard to accept the $1000 we charge per license, you can't really use a consulting model in these cases.
The plugin idea sounds fine, but firstly that is a feature that would have to be added with no expectation of that development time being funded, and secondly some of the features that are requested are not easily done in a plugin style.
I would say that about 70% of the features that are asked for would be really good features that would add value to the product if only they were done correctly, this is why I want some time to develop the next version instead of doing a quick fix that works for 1 or maybe 2 customers.

Tuesday, August 19, 2003


Have you considered competing with your employer?  Leave and start your own company.  If your solutions are as hacked as you say, there must be tremendous support issues.  Perhaps the customers would be open to an alternative?

Wednesday, August 20, 2003

Interesting suggestion, unfortunately I don't have all the development tools necessary to do that, and the product has taken a fair while to develop and is a team effort (there are 3 developers here).
If I were to go out on my own, I would rather do something that interested me more.

Wednesday, August 20, 2003

*  Recent Topics

*  Fog Creek Home