You've got an existing application that's a little long in the tooth. It needs to be "upgraded", aka "replaced" or "rewritten". The issues of "What language should we use?" and "Can I do the work?" have been resolved. The questions remaining are "How long will it take?" and "How much will it cost?"
The way things were.
In 1997, I wrote a book, DevGuide '97, that answered the question, "How do you price an application?" At the time, we were builidng new desktop, LAN and Client-Server systems. The slate was clea, not too many legacy applications out there, and those that did exist were fairly trivial, such as the dBASE III inventory application that spent a lot of time opening and closing tables due to the limitations of 10 work areas.
There was a lot of work out there; too much, perhaps, as the limiting factors for generating income back then were the number of hours in a day and the maximum rate per hour one could charge. Regardless of how good you were, the maximum hourly rate that the market would bear was relatively modest, which was a shame. In our business, the difference in productivity between an average and an excellent developer has been estimated at anywhere between 10 and 40 times. The problem was that the market could not discern the different between an average developer and a master, so the master could not charge proportionately more based on his level of expertise.
In response, I advocated a fixed price model in order to make more money. My hypothesis was that if you were highly skilled, you could take advantage of that fact. Price the system fairly for what an average developer would charge. Since you were highly skilled, it would take you considerably less time, thus producing an effective rate per hour that was comparable to your skill level. Your customer paid fair market price and you were compensated in according to your expertise.
Quoting a fixed price, however, required a clear specification of the work to be performed and a historical database of what it cost to do that work in the past. The first requirement - a clear spec - has more and more fallen out of favor, as younger developers denigrated the "Waterfall" methodology.
In 2012, the landscape has changed.
Back in 1997, the variables we had to deal with were fairly limited. Single vs multi-user. File server vs client-server. Maybe a few character-based vs GUI decisions. Those were the days that Microsoft tried to redefine the term "cross-platform" from DOS/Windows/Mac/Unix to Windows 3.1/Windows 95/Windows NT. At the time, these seemed to be huge leaps in capabilities, but as we'll see, not so much.
These days, we have.... a mess.
First, the UI: desktop, browser-based, or mobile? If desktop, which OS: Windows, Mac or Linux? Each OS has multiple windowing flavors - Windows windowing runs from Windows 2000/XP to Win7. Linux distributions are even more varied. And do you need to support more than one OS?
If browser-based, how far back do you support? Even in 2012, more of the enterprise is stuck on IE6 than one would imagine. And how many browsers? It used to be IE, Firefox, and maybe Opera. Now we've got Chrome, Safari... and if you're developing for the browser, maybe you're developing for tablets like the iPad, the Nook, and the Kindle. And let's not forget mobile browsers: iPhone, iPod, Android. And each of those has current and deprecated versions. If mobile (and not browser-based), the market is changing faster than even the Web can keep track of.
Are you exhausted yet? Get a cup of coffee - this is just the UI.
Next, let's talk about back-ends. You've got your various LAN file systems, be it FAT or NTFS on Windows, ext2/3/4, Reiser or XFS on Linux, HFS on the Mac. Writing to these is generally transparent, but there are nuances to be aware of, such as sorting and case-sensitivity differences. Data storage types, from flat files, XML, and common but proprietary database types (e.g. the ubiquitous .DBF and .MDB architectures.)
Or perhaps you'll use a client-server storage device. Microsoft SQL Server? MySQL? PostreSQL? Big iron, such as Oracle or DB2? Similar, sure, but not identical, not even within individual products.
Another option is the cloud, taking advantage of services like Amazon's S3 or Google Docs. If you're writing for tablets or mobile, the field is even more wide open.
And 15 years later, there are *lots* of legacy apps, from the FoxBASE+ vertical with 1988 copyright dates in the headers to last year's mobile on a Blackberry that is being transitioned to new platforms.
Fixed price is no longer an option.
As I mentioned, one of the requirements for quoting a fixed price is a clear specification. The other is a database of historical costs, a record of how much it cost to do a similar feature in the past. The first is passe, and the second is near-unto impossible to acquire with components (UI, backends) that just showed up 9 months ago.
We have a challenge on our hands. Stay tuned for more.
|
