Re^7: "Practices and Principles" to death

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."

Comment on Re^7: "Practices and Principles" to death

Replies are listed 'Best First'.
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...) `;-)`

Replies are listed 'Best First'.

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...) ;-)