Posted: 1/29/2008 10:08:42 PM EDT
| I'm trying to do some research on the costs of software development. I've found plenty of abstract stuff about the various models of what it costs to develop software, but I'm not finding much in the way of actual or average costs. Let's say for an example, your company needs a application. You write up your specifications and take it too a software development firm. They give you a estimate on how much it will cost to develop. What's the average cost of doing that? Is it just a fixed where they just go to several firms and ask for bids and then pick the firm that can do it to spec for the least amount of money? Is there firms that charge like consultants do with hourly rates? If it's the former, what's the industry average cost? If the latter, what's the average hourly rate? |
|
That's a complicated question to answer. Unless your requirements are very simple and very straightforward, you'll need some analysis work done. You can probably find consultants on dice.com and the like who will give you a fixed price bid on the work, but that's not always the best way to go, as these guys will have every incentive to push back on changes to the spec or any increased complexity. Rates vary wildly with the location of the developers (US? India? Eastern Europe? China? Brazil?) and their quality. You might see ads for web programmers starting at $15/hr, and you can surely find programmers who fancy themselves top tier charging $100/hr or more. Flat fees will vary with the complexity of the project, but when the flat fee is bid, the bidder is going to base his estimate partly on how many hours he expects it to take. If you've not managed a software development task before, I suggest you let a contract for some small bit of work; maybe a prototype or proof of concept. See how that goes, and if the group you contracted with made you feel good about it. Let a bit more, to them or another group, and see how that goes. Also, don't make the mistake of thinking software development is like making hamburgers; you generally can't swap out one developer for another without a significant time hit, assuming the new developer can work with the old developer's code at all. |
Well the basis for my question is this, someone came to our department (computer science) with an idea of a software application they wanted. It's somewhat complex, but not impossible. However, it is complex enough that to do it we figured on a team of about 6 people to work on it. They basically came to us and said "can you do this, and if so how much would you charge to do it?" Well the 6 of us sat down, talked it over and figured that it would take at most about 190 hours to do, given the level of complexity they wanted. They wanted to know how much so I basically figured on 30 dollars per programmer per hour, so at 190 hours at 180 an hour that comes out to 34.5k. My thought was, is that a reasonable amount to charge? |
Ah, I see. You're coming at it from the other side. In my somewhat diverse experience, even professional software engineers have trouble coming up with accurate time estimates before commencing a project, particularly if the requirements are not nailed down. $30/hr is cheap by US contract programmer standards, though if some/all of your team are students that's probably average. If you're bidding firm fixed price, make sure the requirements are as nailed down as you can make them before you commit, so you know as much as possible going in. If you're bidding hourly, professionalism demands disclosure that your estimate is just that; an estimate, and that it's at best accurate to within 10%. As an aside, I've not seen estimates figured quite like yours before. If all six of your team would have to work 190 hours to finish the project, that's an unusually even division of labor. You might allow for some wiggle room by saying 200 * 6 = 1800 man hours and leave the apportionment of labor for later. I'll just reiterate, particularly if you're new to this sort of programming, your estimate is wrong. Probably badly wrong. If your client or you are approaching this like an expensive plumbing or painting problem (no offense to plumbers/painters) there will be tears. 1800 man hours isn't really alot, but it's enough that you should consider an iterative approach. Huddle w/ your team and client to come up with a few of the most important features and try to deliver those in, say 40 man hours. Show it to your client and make sure you're on the same page, then do another 40 man hours. Some projects are hard to break up this way, but if you can make yours work along those lines, you and your client are more likely to be happy. |
Thanks for the input, it's very helpful. As to the way I figured it, this is all very preliminary and not at all firm yet. The main purpose of my question was to figure out of the figure I quoted in the preliminary estimate was even remotely reasonable, based on what you say it probably is. I also understand what you're saying about the division of the labor and that's something my team and I are going to be working out. I'll probably post a few more questions as I sorta figure out how this whole process needs to work. |
Exactly. And to boot, most people think "kinda sorta like the sort feature in excel with pretty blue formatting, but web based and can maybe play MP3s and oh by the way must be able to store 13,567 petabytes of information in it's own proprietary relational database format" is a perfectly well described set of requirements. Requirements planning is devilishly hard, and estimating software projects is a discipline unto itself. Not to mention that requirements ALWAYS change throughout development. As time goes by, schedule estimates will slowly converge upon reality but don't expect auto-repair shop estimate accuracy.
Amen, brother.
Preach it. |
I was about to say the above. For anything even moderately complex 6 people for 200hrs each seems real low. I also don't think I'd be willing to do a fixed price programming project, I don't think it would be practical to come up with a reasonable estimate up front, so you'd end up screwing Someone almost every time. |
|
This thread has been helpful. Things I've learned from this thread (and had hunch were true): The requirements always change Fixed price bids are a baaaaad idea If you have to estimate, over-estimate, by a lot. an iterative approach is good. Here's a basic plan: We agree to their job, but only 40 hours at a time, we charge them 180/hr, which would be $7200. That comes to $30/hr for each programmer. The $7200 will get divided up among the programmers based on how many hours each one does, that way if the hours aren't divided up evenly each programmer gets 30 for every hour he put into it. Once the 40 hours are reached, we stop work and meet up with the client and do a progress eval. We just keep doing this every 40 hours until the project gets completed to whatever changing specifications the client wants. This sound reasonable? Now I do see that a monthly hour cap could inhibit speed of development, but I figure the cap itself could be dynamically shifted up or down if need be. |
Always. After over 35 years on and off in this business, the hardest part I see that most people have is deciding what they want. Very often when they see what they asked for they realize they should have asked for something different. I've only seen one project where the customer had a complete idea of what they wanted. When you combine that with the fact that most people writing the specs or managing the programmers have no clue what they need to deliver to meet the vague idea the customer has of what they want, it's easy to understand why most software projects fail. For example, in September I created a prototype in two hours for a customer. It did 90% of what they wanted. I was able to write exactly what they wanted because I talked to them face to face and watched them work through step by step what they wanted automated. I spent about 30 hours of prep work before the two hours of programming. After giving the job of writing the requirements to a former program manager at Microsoft that didn't understand the problem who gave the job of writing the specs to a guy fresh out of college that didn't even understand some of the basic English words used in the requirements and then giving it to three good programmers in India who have trouble communicating, the project still isn't done after three months of work by five people at a cost of over $35k (480 hours at $75/hour). All of them are smart people that understand their jobs. The problem is they're clueless when it comes to understanding what they should do. They understand the how but not the what. Find a programmer that isn't necessarily the best but one that understands what you need. If you do know exactly what you want make sure you practice explaining it to others before talking to a programmer to get a quote. You need to be clear and concise to get the lowest price. In the example above I should have kept a closer eye on what was happening. I assumed because the customer seemed happy, the checks were clearing, and the manager seemed happy that everything was working. Now this weekend I'm going to have to write the entire system myself and toss their work. Working seven days a week and not having time to plan or review causes problems like that.
Maybe. Very often the goal of the development becomes making the next demo look good. The worst thing you can do is ask for a release each day. The two biggest software projects I've worked on had daily releases. I spent four hours per day preparing for it. I also couldn't add big features or plan much past the next day because of that.z |
You bring a good example too the table. I'll relate some experiences from this current job (not my first, but so far the biggest and involving the most money). The guy I'm working with from the client is a artistic sort. So rather than writing out a spec he actually sat down with Adobe Illustrator and drew up step-by-step .jpg images of what he wanted the interface to look like and ideally what it should be doing. I found this extremely helpful in conveying exactly how it was supposed to work by showing what was to be happening at each step. I then sent him a sort of basic survey of important technical specifications. Things like what OS/platform it needed to run on, who would be using it, where the data needs to go and how it's going to be dealt with, etc etc. |
That's also true. Software development is too complex and diverse an activity to permit broad generalizations and always-applicable rules. You can tell the seasoned practitioners by their lack of absolutist remarks like "test driven development is always the best way to build software" or "if only we had a process this project would've been successful" or "always iterate". IMHO iterative development is the right answer more often than not, but only because it forces real client feedback early and often. So, if you slavishly iterate once a week, but the builds just go on a shelf and the client never sees them, or each iteration is just a slightly-slicker demo, you'll still fail. With experience you gain the confidence to use your judgement on a case-by-case basis and decide what's best for your problem. You'll be wrong sometimes, of course, but it's better to do what you think is right and be wrong than do what some professor or asshole told you was right and be wrong. If you doubt this, I defy you to find _any_ qualitative statement that can be posted on high-traffic software engineering boards without significant objection. "GOTO considered harmful?" Nope. "Perl sucks"? No. "Perl rules?" Def not. "Tests are good"? There's always one guy. "Everyone should do CMMI"? Not if I'm on the board. |
|
I'd offer that the biggest anchor I've seen in software development is the lack of a controller and the lack of technical design. In the bad situaitons I've seen, often programmers are given tasks, they go and do them in a vacum without conferring much with other programmers. They do their own mid and low level design (or just hope and pray) and though their module works fine (stand well on its own), it does not work and play well with the other guy's module. Debug code in that state really compounds the problem. There needs to be someone who spends most of their time not coding but herding the other programmer to make sure they all stay on the same plan and move is same general direction. "No, you can't use that design pattern just cause your Ego likes it, even though it is more efficent, the other coders aren't good with it and they can't: 1) use your modules effectivly 2) they can't fix it either. And you, don't make a mid-course design change because of a shortcomings in the design and not tell other people about it till after their builds fail to compile correctly" I think the Army calls it logistics.. |
That's a tombstone-grade statement, dude - meaning you should have it engraved on your tombstone in the hope that it will be preserved for posterity. Concise, accurate, and totally to the point. Bravo. 
Well, Perl DOES suck, so I guess the above is the exception to the rule. 
|
That's precisely my job in all of this, as well as communicating between the team and the client. |
Read THIS and THIS  You might also look at the free estimation tool the author's company makes available at www.construx.com/Page.aspx?nid=68. |
|
I hope your $30 an hour contains some liability catchment device. A corporate structure is a requirement. When your personal items are on the block for breach of contract, you'll remember this as a missed opportunity. phrased another way, when you're 30,000 man hours in and the customer doesn't have operable software, he's going to start suing. |
We'll be doing this through a LLC and the Business Law professors have been very helpful. |
I'm not about to argue with you, but I dare you to stand up and say that at the next USENIX conference. You'll find out just how fearsome a gang of overweight bearded curmudgeons in overalls and pretentious hats can be when they're angry 
|
In most states you can form an LLC with a form and a fee. I've always done that for my contract gigs. Just make sure you don't do things to pierce the corporate veil, as the biz law guys say. |
"Even seen a herd of cattle stampede when they got no place to go?" -- Reynolds, Firefly |
I've been doing that, plus talking to some of our instructors in the Engineering and Comp-Sci departments, many of whom have worked in industry. |
|
I can't help but throw my pennies in the ring on this subject. There's not a lot to add that hasn't already been very well presented here. But... just a couple of quick notes. his Second, if you use the iterative approach (and you probably should), plan all of the iterations in advance. Yes, they will change but there will be far less chaos involved when they do. And finally, you should really, really, really try hard to get the client to nail down the details wherever possible up front. Try not to let them answer you with any phrases that resemble the following: "Well, I basically want it to pull the data and give me the results." Are you able to discuss the nature of the app, either here or privately? I, and others here, might be able to provide better Planning & Approach insight. Also, if you feel that the task might be "too much", I own an IT Development & Consulting firm. My current clients include AFCC (U.S. Cyber Command) and Fortune 200 companies. I promise this isn't a shameless plug because I am not going to mention my firm's name and I pay very healthy finder's commissions. Regardless, best of luck with the project and if you have any questions, don't hesitate to ask. I will help if I can. My personal email is [email protected]. |
Email sent! |
