Short term and long term programming techniques

Posted 18 Sep 2002 at 05:11 UTC by Alleluia Share This

By arranging the way you manage software development, you can reduce the need for change requests, and make money more honestly by liberating your customers instead of making them dependent upon you. Here are some rough ideas (suggestions welcome) to begin people thinking about how to keep quality in the code, rather than in marketing. Marketing should optimally rest largely in word of mouth, because this is how quality propogates naturally.

Short term software
expensive to maintain, manage, and interact with, because it was designed by people who make money from change requests.

Long term software
cheap to maintain, manage, and interact with, because money is targeted specifically to building quality software, not marketing or change requests.

Short term software
requires extensive rewriting in order to add functionality, or to scale to more operators.

Long term software
designed to scale cleanly from one to fifty thousand operators, and is designed to integrate cleanly with all possible future additions. Adding functionality does not require extensive rewriting.

Short term software
upgrades are not backward-compatible, introduce unrequested features, and often make the application run slower.

Long term software
upgrades are backward-compatible, they are a product of detailed customer interviews, and they include code which optimizes for speed and size, because these are part of the natural evolution of sensible software.

Short term software
has no plug-in interface or API so that it can be extended by third-party vendors.

Long term software
both by nature of being open source and within its architecture, has a plug-in interface or API so third-party vendors can add elegant functionality.

Short term software
is hard to sell, and requires a whole layer of salespeople to convince others to buy it and then manage frustrated customers.

Long term software
sells itself, is a joy to sell, and requires technical account managers, not salespeople, to represent it.

Short term software
relies on copy protection schemes to limit the number of duplications because this allows salesmen to sell it and make a commission.

Long term software
needs no copy protection, and is open-sourced from the beginning because money should be made from work, not from selling. Anyone who finds the software can duplicate, operate, or improve it freely, even including people who take advantage of this freedom because in the long run, enough people will pay the fair price for the software.

Short term software
needs marketing and is thus overpriced, which encourages piracy.

Long term software
sells itself and is thus fairly priced, which encourages honesty.

Short term software
tries to accomplish too many tasks with a single application, because such a package can be sold for more money by having "more features." Trying to do too much with one application means more and more submenus and keys on the keyboard are mapped to obscure functions, raising the chance of somone hitting the "wrong" key.

Long term software
is targeted to a specific real-world need, function, or interaction. Intuitive, simple, and redundant ways to operate the software allow for anyone to use it according to their skill level, gracefully learning how to operate it better over time, redundancy raising the chance of someone hitting the "right" key.

Short term software
eventually becomes very difficult or tedious to use because operations change over time but the software doesn't; it includes no internal macro interface because this is expensive to include.

Long term software
includes an integrated macro ability because this allows an operator to minimize tedious and repetitive work, in a manner which can be modified without paying the developer.

Short term software
keeps its data in a proprietary format because this is a way to funnel more money into the developer's hands if changes need to occur.

Long term software
handles all transactions with an open database engine so any other authorized software can retrieve its data. This is true even when the data itself may be securely encoded.

Short term software
tries to handle security issues within the structure of operating the software, which is not practical because security measures introduce operating complexity.

Long term software
leaves security out of operations, and in the hands of specialized security software and firewalls, whose complexity is justified and targeted.

Short term software
is developed after a few interviews with the customer, and without a clear understanding of how it will be made bug-free in a manner that costs nothing extra to the customer, because this is a way to make money.

Long term software
is developed after exhaustive interviews with the customer, including meetings with all people who will operate the software,wherein there is an extended question-answer period. Bug fixes and change requests are included in the final fixed-cost contract, which means that the initial cost is higher but guaranteed to be a one-time expense.

Short term software
is created by a developer who reads requirements definitions written by someone else, and by a developer who never personally interviews the customer. Sometimes, he never even meets the customer until he starts receiving support phone calls, and often the customer has not taken the time to carefully read the requirements definition to see whether anything was missed.

Long term software
is created by a developer who is present in all requirements definition meetings with the customer (even if he is only a silent geek), and who helps draft the requirements definition, and who is present when each single line of the requirements documentation is carefully read out loud with the customer and discussed so that it properly represents the proposed operator interface, database design, testing, change requests, and bug-fix policies.

Short term software
is developed primarily as a way to make money, secondarily as a tool to help the customer. Thus money is always a factor.

Long term software
is developed primarily as a tool to help the customer, secondarily as a way to make money. Thus quality is always a factor.

Short term software
is designed by a programmer who does not know what constitutes physical labor because he has never worked his body, only his mind, and does no interview with operators, and thus has no understanding of how to accommodate for the real needs of the daily software operator.

Long term software
is created by a programmer who has worked physical labor at some point in his life, and participates in customer interviews with those will use the software. He thus codes with the customer's interests in mind, instead of his own ideas about how to improve things.

Short term software
is created by a coder who lightly tests his software in a real-life environment, relying on the customer to beta-test it for him.

Long term software
is created by a coder who personally operates it for at least a full 8-hour day during pre-release testing, standing next to people who will use it all day long, so that he knows its true limitations and can prepare appropriate workarounds.

Short term software
is closed source, or "pay for the source code" so that the developer can make more money if it needs to be repaired.

Long term software
is open source so anyone can modify it with little effort. this protects the customer, who can go to someone else for help if necessary.

Short term software
insults the operater within source code comments never seen by the operator because the programmer has no compassion for real-world situations.

Long term software
acknowledges its own weaknesses within source code comments, so that it can be easily improved by others.

Short term software
is lightly commented, and must be replaced instead of being improved, because few can read the source code, and those who can rightfully charge lots of money to do so.

Long term software
is internally documented with source code comments explaining each variable, decision-consequence, function, loop, calculation, and operation so it is easily repaired or extended.

Short term software
breaks in fundamental ways, because it was designed quickly by people who make money on change requests.

Long term software
breaks in superficial ways, because it was designed slowly and carefully, by programmers who know all change requests are free, and thus it is worth their time to build it right the first time.

Short term software
is lightly documented, and documentation is not used by customers because they don't take the time to study it.

Long term software
is elegantly documented, half internally with "help" popups, and half externally with troubleshooting and clear instructions including screenshots. The project manager also takes plenty of time to review the help documentation with the customer so he doesn't receive support calls regarding information which is easily found in the documentation.

Short term software
carries cryptic error messages which are useful to the programmer, but which startle and confuse the operater.

Long term software
carries detailed yet friendly error messages designed to inform both the operator and the programmer in case of an error.

Short term software
contains significant changes from the initial requirements definition because the requirements were quickly written.

Long term software
fulfills all aspects of the requirements definition, because requirements actually match what the customer needs

Short term software
costs more than the customer originally thought it would.

Long term software
the cost is fair, and remains fixed.

Short term software
source code is churned out as quickly as possible to meet deadlines driven by money; time is money.

Long term software
source code is a work of art even though the customer may never see it; time is quality. money will find quality, wherever on earth it appears.

be short to become long, posted 18 Sep 2002 at 11:08 UTC by jul » (Master)

Plan to throw one away you will do it anyway (F. Brooks) Release early release often.

You have a point, I believe in most of your assertions.

To be honest it looks more like a mantra than like an informative document.

What are the technics you are speaking of? I really like Steve Cownell (Complete coding Microsoft Press) for instance, one of is point is "there is not such thing as a one best way". It seems to me you give X commandments and no practical advices coming from known studies or experiences. Can you give your reference? Can you explain what you mean in a short description?

Can't see the forest for the trees, posted 18 Sep 2002 at 14:21 UTC by Pizza » (Master)

Short-term vs long-term has nothing to do with OSS/Free Software vs proprietary, nor does it have anything to do with usability or scalability. I've seen plenty of "short-term" OSS/FS software, and plenty of "long-term" proprietary software. And frankly, "making money vs helping the customer" is a ludicrous assertion, as if the software doesn't do what it's supposed to (ie help the user) then you won't get paid for it.

Nearly everything you've written above can be summarized into one simple assertion: The difference between short-term and long-term software is the amount of time you're willing to invest into it. Both at the onset and down the road with subsequent modifications.

The main problem with your idealistic view of long-term software is that you assume the requirements are rigid and well-defined at the onset of the project, and will not change. Otherwise, you have no way of knowing what features to design into your project. If you get a fundamental requiement change, then the "short-term" software is FAR simpler to re-work than the much larger and more complex "long-term" software.

So after all of this, I assert you aren't talking about "short-term" vs "long-term" at all, you're talking about "good practice and bad practice". But even that doesn't apply, as there's plenty of circuimstances where "short-term" software is the RightChoice. I'm not going to spend three months to build the best damn WidgetAnalyzer ever made if all I need to do is spend two hours to build the "WidgetColorChecker" tool and promptly forget about it for the next two years. Opportunity cost is very real.

"short-term" vs "long-term" is an initial requirement, just like any other.

And just to be nit-picky, your comparison on security is backwards. Security needs to be designed into software, not bolted on afterwards. "Short-term" leaves security out, while "Long term" includes security in the design. Remember there's a lot more to "security" than a firewall, which is nothing more than "can person X access this software?" when instead you need to have questions like "can person X modify this data?"

I could go into a lot more, but I have plenty of long-term software to write with short-term requirements.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page