Twenty Five Or So Rules To Build Software That Works And Which Is Easy To Maintain

Approximately 25 rules-of-thumb for producing allegedly smoother software development and maintenance initially proposed by WikiZen TopMind.
At the moment this rant neither summarizes the 25 rules implied by the title nor opens itself well to discussion. To whomever just wrote it: Please add one of these aspects, or consider it for deletion.

I also think the name needs a review, but I don't yet have any alternative suggestions. Maybe something like: CanDesignBeReducedToRules?. I don't think it really needs a number stated since there is no competition yet for different quantities of rules.

I agree. Some suggestions: DesignByRules? (neutral), FollowRulesBlindly? (negative), RulesMakeItEasy? (positive)

How about TableOrientedDesignRules?? Some of the items suggest a procedural or table-driven solution, where an OO approach would suggest something else. For example, "lots of similar case-statement conditions scattered thru-out code suggests that a table would be a better solution" typically suggests polymorphism in a strictly OO approach.

How about 'DesignByCheckList?'!

RulesForRelational? ?. It's usually to some advantage to pick something that is subject to accidental linkage.

Dunno... There are few things here that are rules for relational or SQL development per se. Those are better covered under DatabaseBestPractices. This seems more about client-side business application development using procedural languages like FoxPro.

What specificly is FoxPro-specific?

It isn't FoxPro-specific, it's procedural-specific. FoxPro is an example of a procedural language with named parameters and built-in local tables, hence my use of the phrase "procedural languages like FoxPro". The rules are procedural-centric, with a flavour of data-driven or table-driven development. As I noted above, some suggested solutions might be quite different when using an OO approach, even when working with SQL databases. The rules aren't relational, as the RelationalModel merely describes relations, tuples, and an algebra for manipulating these. It would make no more sense to call this page RulesForRelational than to call it RulesForArithmeticExpressions.

My understanding is that somebody is questioning that a handful of rules can define a software development process in general, not necessarily limiting it to a given paradigm or technique. In other words, they are saying that 25 odd rules are not enough to define good software practices, regardless of the paradigm. It is premature to focus on specific paradigm/tools. These rules listed are simply a specific sample to study.

I was merely focusing on the attempt to give this page a better name. I think RulesForRelational is worse, TableOrientedDesignRules? is better.

But do we want the topic to be about using rules, with table-orientation being a specific example to analyze, or about table-oriented rules?

''I'd rather it be about rules in general. The original topic title suggests nothing about relational, table-oriented, etc. I'd favor DesignByRules? or FollowRulesBlindly?, perhaps with a dedicated links to rules for specific domains.

My original issues when I wrote this rant were that: Mmmmm, maybe we should have both? Rules to test the correctness of the algorithm, and algorithm to measure effort?


Some developers... specially those that are RelationalWeenies, seem to believe that with TwentyFiveOrSoRules? it is possible to build good an easy to maintain software (at least in the biz domain), I believe it is harder than that... or perhaps it is possible to have such an small number of rules... but that doesn't make it "easy"... why? well, because rules are declarative, and that says nothing about the procedure required to fulfill them (I could say, for example, that the only rules needed to go to the moon and back without an spaceship is "to have all the powers Superman has", but that doesn't make it easy, it doesn't even make it feasible) Now.. if we were talking about the TwentyFiveOrSoStepsToBuildSoftwareThetWorksAndItIsEasyToMantain? (specially very detailed AlgoritmicSteps? then we could say (and only after reading them) that those steps prove that building software following a particular recipe is easy (and we of course could only say that for the kind of software that falls inside the scope of those steps, in this case at least in the biz domain).

I'm not sure specifically what you'd like to see. I'd suggest picking an item from the list and focusing on that. For example, you may ask "What does a generic classification system or code template look like?" if that is an area you feel needs to be fleshed out. -t


Reminds me of a lecture back in college A pack of useful lies about the Renaissance... Would everyone feel better if we said heuristics?


I believe I said something like that somewhere, but I don't remember where at the moment. But here is a modified copy of a list from ProceduralMethodologies that can be used as a starting point. Note that I never said such a list would be final, and amendments and adjusts would indeed need to be made as problems with them are found over time. --top

27 Database-centric Procedural Design Rules of Thumb


Dealing with Cutting Edge

A Notion: Don't stop trying to do it because some one or some rule says "You can't get there from here" - Even if you have no idea how you will reach your destination or way-point, take a step that brings you closer!

Whilst that might be reasonable general advice -- though I'd suggest hiring in an expert to progress things when you get stalled, rather than fumbling aimlessly -- I'm not sure it has anything in particular do with building software that works and is easy to maintain.

Maybe it doesn't, but when one is a programmer, while in the midst of an effort of programming, seeking a way to discover new ways to do things, the dependence on the "state of the art", rules, and experts to make a dream come true is not progress, but rather submission to "this is the way to do it" thinking. To make good art, one does not copy and paste structures and methods, one rather finds a way to enhance and express, create and actuate that work not only well, but excellently. If one is simply finding another way to count money or store information, to edit some text, or to communicate with ones peers, reliance on what already works well or dependence on others expertise is certainly called for. But when you want to go where they say "You can't get there from here", you have to bravely and intelligently seek a way to get there that others can follow. You cannot get to new places following old paths, you must make your own path.

{I never say "can't be done", but rather give an estimate of how long it will take to complete, or if too new or "far out", then give an estimated amount of R & D time before the options are known. Generally one should produce a proof-of-concept before going full-bore into an app that depends on the "new thing" to work. Work out the big mysteries first before planning the details surrounding the thing. One shouldn't even start planning the details if there is a big fat question mark hovering around the project regarding new key technology. Don't start writing a FlyingCar Tracking System until you know that the car actually flies. The above context is where those involved generally know the domain and are not in Columbus Mode. Managing R&D is generally another topic. Note that there is already a rule above called "Do the hardest or least-certain parts of the project first." -t}

The tracking system already exists, one has but to put the geolocational component in it when it becomes. Often people are found reinventing systems to do something that has already been done. What I like to do is keep track, not of flying cars, but of useful systems.

I do not provide estimates of how long, since what I am doing is not funded by anyone else and is not a project someone else owns. When done, what I do that can not be done may become useful for others, but for now I build what I build as a Lone Programmer and make it useful as another tool in doing more of the same. Thus far my storage requirements have exceeded several terabytes. All of which I continually review and refine. The Ten Terabyte System I spoke of years ago will soon become a normal minimum. What I am doing is making all that stuff into information which is UsefulUsableUsed.

The above generally assumes team-based projects.
CategoryMethodology, CategoryBusinessDomain, CategoryModelingLawsAndPrinciples, CategoryProcess
JulyZeroSeven

EditText of this page (last edited November 14, 2014) or FindPage with title or text search