June 15, 2009 at 5:07 pm
Comments posted to this topic are about the item The Simple Estimate
June 16, 2009 at 5:13 am
I don't think that there is less trust than there used to be, or even less trust than there should be in most cases. I see two parts to this:
- Trust is earned. On the software side we haven't done a very good job at earning trust collectively as an industry, or collectively as an IT team within companies. Unfortunately individual trust - while often earned - doesn't translate to assurance that things will go as stated
- Trust is related to risk. It's relatively easy to trust a co-worker with $20 to pay for your lunch expecting to get change back, but would you trust them with the credentials to your 401k? If you purchased your next house from your best friend/next door neighhbor/etc, would you be willing to skip the title check to save a few hundred bucks?
I think it's easy to say we need fewer contracts, more trust, but I've always disagreed with that position. Why is it wrong to not only come to an agreement, but work through the details, including what will happen if things go wrong? Isn't that the responsible thing to do? I think calling that a trust issue is a miss characterization.
June 16, 2009 at 6:01 am
My guess is that when you ordered your garage door, you did not get into specifics other than the basic measurements. That is, you didn't haggle over the motor used for the garage door opener (if you got one), and you did not announce that you needed a picture window in the garage door halfway through the project. You probably did not change the color of the garage door when the project was 75% done. And you probably did not specify that you wanted the garage door to open sideways when the project was 90% done...
See where I am going? In my long career of software development I have learned that the reason trust takes a beating is because there is rarely a spec that is solid and doesn't change at some point along the development road. I think this is the biggest drawback and 'damager' to trust. Someone orders you to build a digital Fokker bi-plane, and within a couple weeks that spec has become an F22 Raptor.
In this last decade of my career I have learned the key to trust and to completing projects on time, and the way people want them is to lock down the spec. Not near the end of the project, not halfway through, but at the very start. Software can always be improved and enhanced, but get a first release out meeting timelines, and development requests - then, and only then, should there be discussions about features beyond the initial spec.
We should also slap your wrists a little bit on this one... Garage doors are physical... Software is not.
Next time, ask your guy to build you a virtual garage door and lets see if the project goes all that smoothly! 😀
June 16, 2009 at 6:08 am
There's reasons there are contracts in business. People want more than they are willing to pay for and they think software is the land of magic, not the land of work.
June 16, 2009 at 6:42 am
I've gone both ways on proposed solutions.
Had a prior employer, they said what they wanted, I said how long I thought it would take, they said yes/no on the project and where it fit in priorities, and that was it. If they said yes, I produced it and then slapped together some quick documentation, or left that to comments in teh code. No long proposals, no reams of paper, just a few notes from a meeting and maybe a quick e-mail explaining the whole thing to users.
Current employer wants everything laid out in UML embedded in a multi-page Word document with bullet points and a table of contents. Has a specific minimum of data, etc. Needed to comment out one line of one proc to remove a business constraint that was obsolete. Took 7 pages and two meetings just to approve the project. Took one minute to open the proc, comment out the line, run it in dev, and make sure it worked. Then had to build it into a "service pack" for the database, with a formal layout, etc., log it into source control, and so on.
Both ways work. One is great for getting a lot done fast, but not so good for documentation. The other is great for documentation and review, but means that even simple things take a lot longer to get done, and complex projects have weeks added to them by the process. Can't argue with either one in the environments they were being used in. (Both had dev vs production environments. That's the minimum. The difference is purely in terms of project documentation.)
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
June 16, 2009 at 7:00 am
On Friday, a guy named Randy knocked on my door. He owns a paving company and had just finished doing some work up the street and have left over pavement. He offered to remove all the weeds growing out of my driveway, patch the holes and top coat it, etc. We looked around, he marked down everything that needed to be done in chalk and I asked how much. He said $500 if I paid cash, $525 if I cut him a cheque and I wouldn't pay a dime until I was satisfied with the job. His guys were there in 15 minutes and done by the time I got back from the bank with the $500. They did some other houses on the street too. No contracts, one of his workers gave me a receipt at the end while Randy was down the street lining up more sales.
Really, this is what a good project manager should be doing. Lining up work, giving accurate estimates to the business people and explaining clearly to the workers what needs to be done. A professional crew like that with all the right tools will get the job done right in a short amount of time and it's easy for them to earn the trust required to get things done without being bogged down in paperwork.
June 16, 2009 at 7:12 am
Software development projects most always have hours that are spent on research. There is a difference between producing code and researching the latest whizbang technology or external datasources. This research portion of software projects is what kills a lot of schedules because its an unknown. The other factor that kills schedules is feature creep. Your garage door project didn't have feature creep nor did it require any research . Niether did Jason's landscaping project. Imagine having to write the same software for 2 different customers. They have the exact same specs. The first time you write it, you are more likely to miss the schedule or budget. The second time, you'll nail it. Unfortunately this never happens in the software development world. Every project is different. Yes some components are re-used or are purchased from third parties, but the overall deliverable will be different each time.
As for building trust, the best thing a developer can do is identify the unknowns and be up front with the customer about it. 🙂
June 16, 2009 at 8:34 am
I was expecting these types of responses, but I wasn't sure quite how I wanted to frame this. And Mr. Blandry, wrist slap noted and it stings!:hehe:
We definitely have to build trust, but I think that's an issue. We aren't working to build trust as an industry. I think some people are, and they end up being the stars, the go to people, but wouldn't you think that on small projects, more people would be able to estimate well and build with more certainty?
I know a garage door is a relatively simple spec. Color, style, size, that's about it. However a lot of apps I've been asked for are very simple as well. They might evolve, but they are simple to start with. I've built a few that started small, almost on a handshake (inside a company) and delivered them on time, and the client uses it, though they always want more. That's OK, they need to "pay for it". In that case it's freeing up time from me, making more changes, constantly evolving.
Kind of like a handyman. We use them for small stuff, and ought to be able to work quickly, easily, and on time/budget. We might want stuff altered as we get it done, or enhanced, but it's simple. For larger stuff, we get a builder/GC, and enter into a contract.
June 16, 2009 at 8:48 am
For additional context...
We had specs gathered by BAs for a relatively new team of developers. The BA work was 6 months ahead of the developers. The first team failed to deliver. The next team, us, came in and found that the spec was not only not what we needed, but missing things we needed. Because the BAs were so far ahead, they claimed they could not take input from us on how to improve their process to get what we needed formatted in a useful manner. So, our evil project manager takes a bunch of wild guess estimates, which doubled what anyone expected the functionality to take, which inevitably fell flat as.... We had to redo the BA efforts and redefine the needs. As the customer saw our output, they changed their mind and added functionality. And bless me, if our BAs, aren't still 6 months ahead of us, gathering requirements the same way and making our lives all the more difficult. All along I have pointed out that our root problem is understanding what the custmer wants, getting them some feedback early to let them hem and haw about how they want something to look/feel, and getting the results of those discussions back to development. Instead of acknowledging that development has to do all those things and meet a timeline that is based on nothing but hopes.
June 16, 2009 at 5:31 pm
They pay us a lot of money to develop applications, design databases, etc. Once its simple, they will pay someone else a lot less.
June 16, 2009 at 7:43 pm
All I want to know, is how do you go about posting a small job RFP to the internet for people in your local area?
I have a need to have my garage door rehung and don't relish contacting a lot of overpriced specialists via an extensive web search or to pay a local help wanted jobs board to advertise for someone. I would love to post a requirement and have handymen/contractors call me. How do you do it (I am familiar with government and other enterprise RFP's but have never seen it done at local - small job level.)
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." -- Martin Fowler
June 16, 2009 at 8:58 pm
I have typically used referrallist.com, but it's only in some areas. They guarantee the work, and they give firm estimates, but I've found them high for some things.
For the most recent one, I used servicemagic.com, and was amazed to get about 5 calls in 30 minutes. It was stunning, and they were all in similar price ranges.
June 17, 2009 at 6:58 am
Nicole Garris (6/16/2009)
They pay us a lot of money to develop applications, design databases, etc. Once its simple, they will pay someone else a lot less.
Amen to that!
June 18, 2009 at 10:54 am
Bob Griffin (6/17/2009)
Nicole Garris (6/16/2009)
They pay us a lot of money to develop applications, design databases, etc. Once its simple, they will pay someone else a lot less.Amen to that!
not sure I agree with this, I hear what you're saying, and there is a lot of expertise goes into building a good product. But if you can deliver the same product (or even one slightly the worse for wear) with way less red tape, the customer is more satisfied and more likely to return for additional work.
I think this isn't about unqualified people building crap products, and that being less of a hassle; it's more about cutting out the unnecessary stuff that sits in-between a satisfied customer and the production group.
If my handyman is installing my garage door and I ask him to make it open sideways, and the only thing I have to do is agree to the fact that now he has to rip out what he started and rebuild it, I'm much happier.
If I have to meet with him six times to discuss exactly how it's going to work, fill out specification documents, etc; I'm more likely to go with what he started, even if I don't like it.
But will I call him again?
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
June 18, 2009 at 1:06 pm
I don’t think software projects can be simple because software buyers always creates scope creep and software companies hire few good developers to deliver few features and repair latter. There is method in the madness and both parties rather spend the more on lawyers than happy developers.
I remember the developer who wrote a lot of stored procedures in a short time one pesky problem none returned the client's data, but companies like such people because the code will create a nice running executable doing nothing. The managers calls it deliverables I call is crap or useless code.
:hehe:
Kind regards,
Gift Peddie
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply