Re^4: "Practices and Principles" to death

[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

[chromatic]

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.

[BrowserUk]

Disclaimer unnecessary. I love good debate. And yours is good. A few counters.

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

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

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