Re^3: "Practices and Principles" to death

[shmem]

You have added nothing to the conversation.

That is, to say it charmingly, not quite accurate. sundialsvc4 added enough to incite you to answer. Now, if that isn't adding something to the conversation, what is it?

update: yes, I won't discuss whether sundialsvc4's post or your reply are substantial; but nothingness often begets enlightenment. I didn't add anything, either...

[sundialsvc4]

Thanks.

Perhaps I could state my curious opinion in a slightly different way:   focusing too much on “practices and principles” is, IMHO, focusing on the wrong thing.

The actual code that you write, to do anything at all, is so secondary as to be an afterthought. Usually, most of the code that I have encountered over the years is indeed “a perfectly reasonable implementation of the designer's apparent intent.” When the code that I thereby encountered was pure crap, it was because it was very obvious that the designer was making the whole thing up as he was going along. There was no “intent.” The project was deemed to be “finished” when the coding stopped, and anything and everything that was done thereafter (i.e. to actually finish the project) was chalked-up to “maintenance.”

If there is really a “best” practice in this business, I submit that it most-essentially consists of:   do not design at the keyboard. Figure out what you intend to do, in all respects, before you attempt to write any code. If the entire project has been worked-out on paper in advance, then broken down into detailed subtasks, then every programmer can simply “do their piece” and they only have to do it once. Guaranteed. You don't have to give a fancy name to some little slice of the code, because by the time you get to that stage the battle has already been won or lost. You are either attaching little names to broken code, which does no good, or you are “gilding the lily,” which also does no good.

Twittering about buzzwords is no substitute for thorough and careful design ... started and completed before (yes... before!) any(!) coding work is begun.

The people who insist that what I just said is “pure garbage” have a name for themselves – it's called “extreme programming,” and it boils down to “you're brilliant as long as you deliver ‘no, no, that's not it either’ once a week.”

You can attach a label to anything. You can write a book, which Tim O'Reilly will happily publish at least for a while, but excessive studying of individual parts does not illustrate how the entire project must fit, and be fitted, together during the all-important pre-construction process.

[BrowserUk]

Figure out what you intend to do, in all respects, before you attempt to write any code.

You're a man of the old school. Waterfall et al. maybe.

Been there and done that. And, for at least 2 in 5 of the projects I was involved in where this methodology was used: requirements were gathered; a design specification raised and reviewed; test plan drawn up; and an implementation plan put in place. Before the ink was dry, the project was cancelled because someone had beaten us to the market or customer.

Customers rarely know what they really want until they see it. Market places evolve faster now than ever before. Requirements change over time. But mostly, it is very rare, unless you are designing your 100 th XYZ, that anyone can sit down a write a specification based solely upon what they already know.

Whilst it is very rare that a radically new algorithm (for anything) is invented, small evolutions happen all the time. And once you start combining several general purpose algorithms, with domain specific knowledge, the scope for innovations grows exponentially. Predefining everything becomes a good way to stifle such innovations, and is a death knell in emerging markets and growth areas.

Flexibility is the key. And that requires starting projects with some level of unknowns, and living with them. Prototyping as you go. Active and willing incorporation of changes to requirements on the fly is no longer taboo, nor even a nice to have, but one of the requirements of most every new software project.

Whether it is the ability to send updates to remote rovers on Mars; adapt to the overwhelming demand for openness on the iPhone; or competing with the ever-evolving feature-itis of your competitors search engine or community web site. Passive, fixed in stone development cycles are a thing of the past. And on a personal note: Good riddance.

[sundialsvc4]

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