Page 1 of 3

Give me your best estimates...

Posted: Sat Dec 08, 2007 2:25 am
by alex.barylski
In giving a sales presentation to a client I stated that unfortunately, almost all software is not "designed" but rather starts as a simple concept and explodes into a messy hack (which is true of 95% of applications I've looked at/worked on both open source and proprietary).

I explained that the disadvantage of rushing software to completion (such as the motto in open source - release early, release often) often leads to rapid application development, but unfortunately comes at the cost of poor software design. The larger software projects get, the more difficult it is in finding a replacement developer, the more expensive training becomes and the mroe likely your developer will just quit on you...

I said, that in my experience (which I was not lying) 50-85% of developer activity is spent on technical support (assuming your shop has developers handle this) and debugging/patching software with only 50% (at best) of developer resources actually being spent on productivity/enhancements/features/etc...

The sales pitch is that I aim to reduce that percentage to less than 15% (admittedly I was being optimistic - but it's a sale pitch not a confessional). :P

As a rough estimate I have worked for a little over a dozen different small/medium sized software companies (50,000-100,000 SLOC) over a ten year span (primarily in PHP) and worked on say 100 different open source/closed source software applications.

What have your experiences been? Would you agree? Would you say I've had a bad experience? More importantly, if you feel my experience has been poor and yours was not, would you mind explaining what you feel made the difference? Was it software design/principles that made a difference and would you care to give me a reference (name, email and quoted statement on what made the difference?)...

Cheers :)

Posted: Sat Dec 08, 2007 2:59 am
by Maugrim_The_Reaper
I think you're not far from the apple tree ;). A lot of web shops do end up rushing out hacks and in my line of freelance work it's painfully obvious just how rushed some times are. I still believe a lot of the rushing is a major lack of discipline depending on the client type. If you have small clients that "want it now" and give an unrealistic time schedule (pulled from Marketings/ITs bunny hat) then rushing is IMO almost inevitable. Larger client tend to have some sense of reality and usually someone who understands that a rushed job is generally a Bad Thing (TM).

Your 15% is achievable, if you have a sufficient suite of tests. Rushed jobs, no tests, and that 50% (which is optimistic even!) is almost certain. I do still advise folk that irrespective of methodology debates ;), being efficient is still a matter of discipline, planning, and efficient use of time. Methodologies exist to achieve those targets, not magically grant them to you. You can practice XP and completely put your project time way out into space if you're not watching the big picture (and dumping XP when needed in some areas which is rarely mentioned - don't let the methodology rule you, you rule it).

In my development work, applying XP, being anal about continuous integration, and making absolutely certain the client was on my page about feature value and timing, and what happens when you expand them two weeks before a deadline without consultation, was important. The anal bit is down to keeping the shop clean - it is way too easy to let the small things slide so far that the end of project cleanup of them is quite possibly the most horrible sort of development possible (i.e. mind numbingly boring).

Posted: Sat Dec 08, 2007 5:22 am
by patrikG
Depends what you're pitching for. If I was your potential client, say a marketing guy, I'd think: "Oh, one of those dyed in the wool techies who strive for perfection and never finish a project", shake your hand and never contact you again.
If I was a fellow developer I'd say: "Yeah, you're right, it's shocking isn't it. Now tell me how you would avoid this." Depending on how convincing you'd be in demonstrating that you're able to avoid those pitfalls, I'd consider contracting you.
As a small business I'd think: "I want my solution on the web and I am, frankly, not interested to hear all this tech-speak, I don't understand 95% anyway."

And the moral of the story: truth is a selective enterprise and you have to speak to clients about how you can help them, not about your own problems.

Posted: Sat Dec 08, 2007 12:53 pm
by alex.barylski
Maugrim_The_Reaper wrote:Your 15% is achievable, if you have a sufficient suite of tests. Rushed jobs, no tests, and that 50% (which is optimistic even!) is almost certain. I do still advise folk that irrespective of methodology debates , being efficient is still a matter of discipline, planning, and efficient use of time. Methodologies exist to achieve those targets, not magically grant them to you. You can practice XP and completely put your project time way out into space if you're not watching the big picture (and dumping XP when needed in some areas which is rarely mentioned - don't let the methodology rule you, you rule it).
While I don't follow XP religiously (obviously no team programming and TDD is sort of non-existant) I have seen substantial differences in my development time compared to previous projects. I do eventually plan on unit tetsing but more for keeping the program clean once running (assisting in refactoring, etc) I'm not entirely convinced of it's benefits in helping you develop a proper interface, I probably just have to use it a couple times (effectively) and I would start, but...

As a lone developer who is pedantic about details and spends 1-2 hours a day skimming/scanning his source code looking for bugs, issues, etc...I am confident in the results hitherto. Once I introduce another developer into the mix, then tests sky rocket in importance, much like SVN will.
patrikG wrote:Depends what you're pitching for. If I was your potential client, say a marketing guy, I'd think: "Oh, one of those dyed in the wool techies who strive for perfection and never finish a project", shake your hand and never contact you again.
Hahaha...sad but true... :D

Yes I have been guilty of that.

This sales pitch is months ahead of schedule. Simply informing the client of what's to come. It'll be a hosted application but the benefits of my latest development efforts will still indirectly affect the client. Quite simply, I will spend less time on bug fixing and more on updates or tangible features...customizations, etc.

The pitch was not for a development contract, but the sale of a finished product...I'm not taking any money just sparking interest/testing the waters so to speak.

I'm anxious (yet patient) to finally complete the application and see how it responds to real world requirements, etc...

I'm still a good 3-4 months off...so I have plenty of time to f**k up and start mindlessly hacking my code...

It's interesting that I have at least someone agree with me...but I've have been seriously hardpressed to find a projects which allowed more time spent on feature requests than bug reports. I would love to know of an existing application where the experience has been otherwise...

It'll be interesting for me to see how everything goes...I keep a daily log of development efforts, SLOC history, etc...this is true of most projects I have worked on as well...comparing the data should yield whether or not I was accurate in my predictions...

Cheers :)

Posted: Sat Dec 08, 2007 2:23 pm
by califdon
patrikG wrote:Depends what you're pitching for. If I was your potential client, say a marketing guy, I'd think: "Oh, one of those dyed in the wool techies who strive for perfection and never finish a project", shake your hand and never contact you again.
If I was a fellow developer I'd say: "Yeah, you're right, it's shocking isn't it. Now tell me how you would avoid this." Depending on how convincing you'd be in demonstrating that you're able to avoid those pitfalls, I'd consider contracting you.
As a small business I'd think: "I want my solution on the web and I am, frankly, not interested to hear all this tech-speak, I don't understand 95% anyway."

And the moral of the story: truth is a selective enterprise and you have to speak to clients about how you can help them, not about your own problems.
You hit the nail right on the head, patrikG! I was about to respond in the same vein, but you said it all, and quite clearly!

Posted: Sat Dec 08, 2007 4:45 pm
by alex.barylski
I suppose only time will tell how successful I am in pitching my pitches. :P

Posted: Sat Dec 08, 2007 4:55 pm
by John Cartwright
patrikG wrote:As a small business I'd think: "I want my solution on the web and I am, frankly, not interested to hear all this tech-speak, I don't understand 95% anyway."
Very frustrating working for this kind of client most of the time. While I appreciate how they may not understand some of the more technical details, that is why they are paying us. My lifelong lesson is shop around for clients wisely :D

Posted: Sat Dec 08, 2007 5:45 pm
by alex.barylski
Jcart wrote:
patrikG wrote:As a small business I'd think: "I want my solution on the web and I am, frankly, not interested to hear all this tech-speak, I don't understand 95% anyway."
Very frustrating working for this kind of client most of the time. While I appreciate how they may not understand some of the more technical details, that is why they are paying us. My lifelong lesson is shop around for clients wisely :D
Now I get to say ditto. :D

Ditto. :)

Posted: Sun Dec 09, 2007 10:52 am
by feyd
I guess I've been quite lucky. The only projects that spiral are of my own creation. One could say it's because I don't lock myself into a design document. What it actually boils down to is the historical triangle of quality, turn around time, and price. No matter what, they have to equalize or someone's getting cheated. That alone shuts down a lot of clients dragging their feet.

I barely get calls asking for small jobs anymore. I love that. :)

Re: Give me your best estimates...

Posted: Mon Dec 10, 2007 5:52 am
by Jenk
Hockey wrote:I explained that the disadvantage of rushing software to completion (such as the motto in open source - release early, release often) often leads to rapid application development, but unfortunately comes at the cost of poor software design. The larger software projects get, the more difficult it is in finding a replacement developer, the more expensive training becomes and the mroe likely your developer will just quit on you...
You've got the wrong idea with that.. the "release early, release often" is NOT a rush, it is the complete opposite. It is simply to stay, do not hold back finished items until you have a big bunch of them, it is to say "If it's finished, create a new release, no matter how small."

Re: Give me your best estimates...

Posted: Mon Dec 10, 2007 1:10 pm
by alex.barylski
Jenk wrote:
Hockey wrote:I explained that the disadvantage of rushing software to completion (such as the motto in open source - release early, release often) often leads to rapid application development, but unfortunately comes at the cost of poor software design. The larger software projects get, the more difficult it is in finding a replacement developer, the more expensive training becomes and the mroe likely your developer will just quit on you...
You've got the wrong idea with that.. the "release early, release often" is NOT a rush, it is the complete opposite. It is simply to stay, do not hold back finished items until you have a big bunch of them, it is to say "If it's finished, create a new release, no matter how small."
I think you have been given the wrong impression of the idea...or have been fortunate like feyd.

The idea means well and practically it might even make sense as it should (in theory) let you catch bugs sooner than later...the problem is that reality has shown this to be anything but true. Show me one open source application (lets stick with PHP) and I can show you 10 that suck. Perhaps the founding developers have it wrong when they employ the open source model, but my point was, that it fails more than it succeeds. Not that the idea is fundementally flawed.

Posted: Mon Dec 10, 2007 1:27 pm
by patrikG
"Release early, release often" applies in conjunction with the other tenets stated in Eric S Raymond's "Cathedral and the Bazaar" and works very well with principles of open-source development such as "How Many Eyeballs Tame Complexity".
However, if you work on your own, your software is not open source and/or you are the only developer it naturally has no benefits whatsoever.

Posted: Mon Dec 10, 2007 2:05 pm
by alex.barylski
I'm not saying that "release early, release often" *can't* work but rather *doesn't* work...which if you look at all those open source projects on SourceForge...the truth is in the pudding. Perhaps it's an example of a little bit of insight being bad for you...I'm not one to say. Sure, If it's used in conjunction with other best practices, it might be successful, but rushing software leads to poor quality (It's a fact of life with anything really).

I wasn't comparing open source versus closed source, although proprietary software is often rushed too - just for different reasons.

Posted: Mon Dec 10, 2007 2:15 pm
by Kieran Huggins
Some of the best developers I know work at Unspace, and they have this to say on the topic: http://unspace.ca/innovation/speak

Posted: Mon Dec 10, 2007 2:35 pm
by patrikG
Hockey wrote:I'm not saying that "release early, release often" *can't* work but rather *doesn't* work...which if you look at all those open source projects on SourceForge...the truth is in the pudding. Perhaps it's an example of a little bit of insight being bad for you...I'm not one to say. Sure, If it's used in conjunction with other best practices, it might be successful, but rushing software leads to poor quality (It's a fact of life with anything really).

I wasn't comparing open source versus closed source, although proprietary software is often rushed too - just for different reasons.
I suggest you read the article I've linked to. As I said above, "release early, release often" doesn't work in a non-shared development. The reason why there are a number of stalled projects on sourceforge is that they have never reached critical mass in their number of developers. If they had, "release early, release often" would apply.