|
in reply to Re: "Practices and Principles" to death
in thread "Practices and Principles" to death
Spoken as someone who doesn't understand metainformation. Bravo. You have added nothing to the conversation.
It is only when something is named that it can be discussed. Period. It is in how the naming boundaries are made that true understanding can come about. Those patterns you deride allow me to discuss rather high-level concepts with other practitioners of the art with much fewer words. This allows me to communicate more clearly and, more importantly, to think more clearly. Abstraction is one of the few attributes of humanity that separates us from the animals, that allows us to survive when we are, frankly, one of the weakest animals in the kingdom.
Or, to put it bluntly, discussing programming without the metaprogramming is like programming without subroutines.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
|
Re^3: "Practices and Principles" to death
by shmem (Chancellor) on Mar 03, 2008 at 23:29 UTC
|
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...
--shmem
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
| [reply] |
|
|
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.
| |
|
|
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.
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.
| [reply] |
|
|
|
|
| |
|
|
|
|
