Re^6: "Practices and Principles" to death

You're free to call me “an old (school) man” if you want to ... I don't mind a bit, and I will stick to my guns on this one. (And not keep belaboring the point. Promise.)

I've heard the argument that “the market is changing too fast to allow time to plan ahead,” and I've read several glossy books that say exactly the same thing, and after reading and considering them all I draw the same conclusion: “Buncombe!! ... Your Mileage May Vary.”

Disclaimer: I say this in the spirit of debate ... “nothing personal.”

Customers don't know what they want before they see it, and that is to be expected because they are not engineers. But you do not have to construct something in its smallest-detail before you can show something, say to a focus group or even to others within the company. Just whip out a dry-run set of HTML pages, put the files on a place where the others can find it, and crank-up a conference call. Draw on a white-board and send a photo of the board on your cell-phone. Write it on toilet-paper and send it by carrier-pigeon. Whatever works. Meanwhile, the infrastructure-designers are making their own preliminary explorations, designing the foundations that they know the final “show,” whatever it is, will require. Several design-teams can be working in parallel, but all of them are designing, not coding (yet).

Only a fool would build a building, show it to the customer and say, “is this what you want?” No, the customer is shown and must expressly approve the plans, and the inspectors will pore-over those plans too. Mistakes can happen: an entire wing of a local school was once constructed with not a single electrical outlet. (It was, unfortunately, omitted in the plans.) Computer software can cost more than a school.

It does no good to be “quick to market” with what you think to be “finished code” when you are destined to discover that the code you hastily built is ... wrong. It is much harder and more dangerous to tear-apart an existing software structure than to decide, having not built it, that what you would have built would have been wrong. On the other hand, with plans properly drawn-up and agreed-to, everyone can meet deadline at the same time ... including the usually long-suffering technical writers and marketroids.

I will never, ever be persuaded that anything is gained by “figuring it out as you go along.” I attach no importance to “deliver something once-a-week and show it to them and ask them if this is what they want.” After two or three iterations, they're going to conclude that you don't know what you are doing, that you're not really listening to what they say, and that you consider them to be made of money. If they have an alternative, i.e. if it's their own money that they're spending, then they're going to find that “alternative,” and guess-what, it won't be you. If they don't, then your workgroup is the only sole-source they have, and hopefully your development-costs are not coming from their budget.

Having said that, I do recognize fully that many development-projects can be, and should be, devised and even deployed in (small) stages. But you need to figure out in advance what those stages will be, and to determine to your own satisfaction the “probable scrap-cost.”

Remember, in my humble... any code that is written by a professional programmer but that does not make it into the production system ... is pure (s)crap, nothing more or less. I paid tens of thousands if not hundreds of thousands of dollars and who-knows how many days or weeks of schedule-time for ... for absolutely nothing. I can't afford such overruns. I am not willing to “chalk them up to R&D.”

There is “a calculated risk” of scrap, but let that risk be calculated, not chalked-up to experience. Experience may be the best teacher, but I can't afford the tuition at her school. I do not want “scrap.” Anytime. Anywhere.

Let me clarify just where I'm coming from: In the business that I ran for 15 years, we made fixed price, time-definite task-contracts on everything. Many small, definite stages. You knew what you would get, when you would get it, and how much you would pay. There was a 30-day warranty on everything. So there was no room for error ... and we didn't make them. We could not afford to make them, and this was by-design. Our business was always profitable for as long as we chose to run it, because of(!) those self-imposed conditions. That was our market hook, and nobody else out there was doing it. Our market included a lot of small businesses – it was “their money” we were spending – as well as a fair number of big-companies who outsourced work to us because we did a better job and a faster job than their I.S. department would have done “when they finally got around to it two years from now. Maybe.”

This is What The Customer Wants, and I don't buy the notion that we cannot deliver that to them... when we say we will, and for the price we quoted, guaranteed. “That's my story and I'm stickin' to it.” :-D

Replies are listed 'Best First'.
Re^7: "Practices and Principles" to death by chromatic (Archbishop) on Mar 04, 2008 at 22:38 UTC
Only a fool would build a building, show it to the customer and say, “is this what you want?” Most of us on this site can list several important differences between a building and a piece of software. For example, if you want to turn your nice one-bedroom cottage into a 318-unit apartment building, you're going to have to dig a slightly larger hole and wait for a few more yards of rebar-reinforced cement to dry. Software tends to have fewer physical restraints. That's one reason we don't call it hardware. In the business that I ran for 15 years, we made fixed price, time-definite task-contracts on everything. I suppose if your definition was merely "Delivered what the customer used to want on time and on budget" then you deserve congratulations. Me, I stopped arguing with customers that they still had to pay me to get what they didn't want anymore several years ago. Unless I build a system that's exactly like several systems I've built before (in which case there's something wrong with my development process), I don't believe in trying to predict the future and suffering the inevitable consequences of occasionally being wrong. "On-time and on-budget" only impresses me if the results deliver working, useful, usable business value to the customer.	[reply]
Re^8: "Practices and Principles" to death by locked_user sundialsvc4 (Abbot) on Mar 04, 2008 at 23:37 UTC
You're not going to build a single thing from, or onto, my “nice one-bedroom cottage” unless you show up with a blueprint or an equivalent drawing. I also expect a firm estimate: if it costs you more money than you thought it would, that's your problem. If it doesn't conform exactly to what we agreed to, I know the judge will give me a summary-judgment. (Judges have done that for me in the past... in my favor.) When people know that I know what they want, for a well-defined piece of work that we have all agreed-to in advance, then there has never been a problem getting paid. Or, getting more referrals than we could use. If the customer “doesn't want anymore” what you contracted with him or her to build ... then you certainly were not ready to start work. Either they threw away their money, or you threw away your time, or both. That's not “being in business” ... that's starvation. The average lifespan for the usual computer-services one-man-band is about two-and-a-half years, so I'm told. We must have eaten a bunch of ’em for lunch and didn't know it. And oh, the stories we heard about “corporate I.S. departments!” One crucial aspect of our profitability was that the “task orders” that were an integral part of our contract system were small and well-defined. The first one or several were for specifications-only. Often the first task was to (be paid to...) work out and to discover what to do. (The core idea for this came from Hermann Holz's various books on Consulting Contracts, still in-print. “Priceless.”) Say, were you working in Phoenix, Arizona in the mid-to-late 90's? If so, I owe you dinner and several strong drinks. I made a lot of money off of you... `;-)`
Re^9: "Practices and Principles" to death by chromatic (Archbishop) on Mar 04, 2008 at 23:51 UTC
Say, were you working in Phoenix, Arizona in the mid-to-late 90's? I worked in construction in the late '90s, which I find terribly amusing. You're not going to build a single thing from, or onto, my “nice one-bedroom cottage” unless you show up with a blueprint or an equivalent drawing. In the world of software, we call this blueprint the source code. If it doesn't conform exactly to what we agreed to... ... then you probably changed your mind, like customers do, both in construction and in software. If you made so much money with those nearly-mythical customers who know exactly what they want to the point where you can specify it in legally-binding terms before you write a single line of code, good for you. You're the first person I've ever talked to who's ever had one customer like that anywhere.	[reply]
Re^10: "Practices and Principles" to death by locked_user sundialsvc4 (Abbot) on Mar 05, 2008 at 00:16 UTC
Re^11: "Practices and Principles" to death by dragonchild (Archbishop) on Mar 05, 2008 at 01:42 UTC
Some notes below your chosen depth have not been shown here
Re^7: "Practices and Principles" to death by BrowserUk (Patriarch) on Mar 05, 2008 at 00:02 UTC
Disclaimer unnecessary. I love good debate. And yours is good. A few counters. But you do not have to construct something in its smallest-detail before you can show something... I agree entirely. That's exactly what prototyping and RAD are all about. Put together a minimal system as quickly as possible and get feedback before moving on. It does no good to be “quick to market” with what you think to be “finished code” when you are destined to discover that the code you hastily built is ... wrong. It does much more good than being slow to market...and finding what you built is wrong. You have time to fix it. Maybe start again from scratch. Maybe 2 or 3 times if need be, and still be there before your slower rivals. And, in the meantime you won mind space with potential customers. In the business that I ran for 15 years, we made fixed price, time-definite task-contracts on everything. It sounds like you had a fairly specific niche in which you excelled. You had a formula for putting together projects that worked, and you re-used that formula over and again. In those scenarios--I'm guessing web work, but web or not--where you have an essentially standard set of requirements--with customisations and variations--it is possible to construct quite detailed plans and schedules up front. (My 100th similar project quote from above) Again assuming web work. Let's say you've been buzzing along for a few years putting together custom web sites using mod_perl and Apache and Mysql. You've become very good at estimating delivery times etc. Then a customer comes along and throws a nice buzzword at you: AJAX. They've no real idea what it means, but they were shown a couple of Web2 sites. Google Earth, gmail, and a few others and they really like the apparently refresh-less nature of the presentation. They've no idea how their site will make good use of the facility, but they want it anyway. And they seem to have a lot of cash to spend and a lot of new projects in the pipeline. You want some of that business. You have no experience with that kind of site. (A situation a lot of web implementers have found themselves in in the last year or two. Now, you have to do R&D. You have to do it in order to get your first feel for the technology and what it is capable of. You have to do it to get experience of how it changes your formula. You have to do it in order to show your customer the possibilities. And to get them to reach a decision about what they actually want. You cannot put your plan in place, write your specifications, or even gather your requirements until your customer make up their minds. Until you have made up your customers mind for them. That when not just short stages, but indeterminate plans are impossible to avoid. You have to put together the minimum effort and get it in front of your customer fast. It's the only way you can afford to progress. Even if your niche wasn't web work, a similar analogy of new technologies messing with existing formulae can be constructed for most markets. Even big iron code has gone through a sea change over the last 5 or 10 years with customers expecting java or web based front ends instead of 3270 green on black; and massively parallel back-ends instead of linear. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^8: "Practices and Principles" to death by locked_user sundialsvc4 (Abbot) on Mar 05, 2008 at 00:41 UTC
This exchange is fun! `:-)` Now, for the various bullet-points, and then let's see if anyone else maybe wants to chime in... My “prototypes” are not “systems.” They are prototypes. Usually, in the case of web applications, an HTML mock-up that actually can be viewed on a browser (so I don't have to wave my hands too much) but that does not do anything yet. My approach is not to “fix it,” nor to “start over from scratch,” but rather to do the work up-front to make extremely sure that I never have to do such things. As I said, I cannot afford to do such things, and really, neither can the customer. Someone out there has just done a massive amount of un-paid work, or has just thrown away a gob of money with nothing to show for it. My assertion is that, if you find you have to “start over,” or even to “fix it” (in the sense of ... oh, let's face it ... “redesign it on-the-fly”), you were not ready to start yet and should not have started. In the case of, say, AJAX... you have to try to keep up-to-date ahead of time. You'll have to invest some “throw away time” into one or two internal training projects, and maybe some external training. (As much as possible, while you might be willing to invest some “self-training” upon yourself, you don't want to do that for your employees.) In the meantime, don't take-on projects that demand AJAX. Let the other competitors shake the tree for you, even if you lose some short-term work to one of them. By this time, though, your reputation should have preceded you: by this time, customers want you, because they trust you and/or they trust the person who gave them the referral. If you level with them completely, they might commission the project anyway, knowing that you will deliver. Somehow. `:-)` And, of course, you will. Once again, though, I'm not going to deviate from my formula. I'm not going to risk shoving “junk” in front of my customer's face, no matter what. And, I'm not going to confuse my own business objectives with those of my customers. I'm not going to tell them that they should do a project a certain way because I need to get myself up-to-speed in that area; nor am I going to tell them to avoid a strategy because I'm not up-to-speed on it yet myself. (I guess you know you've arrived somewhere when you start to offer your customer a few other names, and they smile politely and say to you, “no, no, we want to work with you.”) `:-O` There's... nothing... to equal that feeling. Oh, how it makes you burn that midnight oil! Yup, I don't miss the 3270. Or that world. (Oui? Non? Oops... we've dated ourselves! Or I have, anyway...) `;-)`