Re: business rules?

Kelly, I love "Armchair philosophy" as well as "Armchair Quarterbacking". Unfortunately this year, I'm a Minnesota Viking fan. To me, this is the most interesting part of software development.

<.02>
My $.02 on the subject....
I agree with your points above about speed, quality, and expense but only in the context or procedural software development. The vast majority of the IT industry is in this mode of procedural software development which is why we are often slow and costly.

There is a solution to this problem that can reverse these attributes and enable to you develop with accelerating speed, rising quality, and reducing expenses. The solution is object oriented programming and frameworks. PHP, Zend, IBM, Java, Smalltalk, SOA, WS REST, etc have been touting the benefits of OO/frameworks for a long time. Admittedly, the adoption of these technologies has been slow. For many of them the complexity masks the benefits. However, a OO/FW approach can enable productivity orders of magnitude over a procedural approach. So development with fast development, high quality, and lower costs is possible today. I had a chance to spend most of my whole career chasing the goal of fast, high quality development. Call it the "Industrial Revolution" of software development. Reusable parts that you assemble together to produce products.
</.02>

Now off to a eat beans on toast then to an xmas party. Have a good weekend all. -Paul


Kelly Cookson wrote:

I think we're talking past each other. I don't think the choice between maintenance, performance, and flexibility is the same as the choice between speed, quality, and expense.
Here is the choice between speed, quality, and expense:

1. Time is required to do a job well. The higher the quality the deliverable of a job, the more time it will take to complete that job.

Agreed but when we do the job, let's make the solution work for ALL similar software requirements NOT just the immediate problem. (For example, if we build a battery, that battery can be used in all sorts of electronics, it is a reusable component. Once designed correctly it can be very quickly integrated and reused. It has high quality because it's been tested and used in other devices, and it's cost is reduced because we are leveraging it in many projects.) Each project you may build more reusable objects that you can leverage along with your previous objects.

2. Labor costs money. The more people work on a job, the greater the expense of labor to complete that job.

All Jobs or programming projects, have a ton of work items that are redundant, procedural programming will have you write code to solve each problem over and over (how many subfiles have we written). Frameworks and objects, can reduce the amount of labor we have to do because we are reusing. (Need a battery? Got one right here... just reuse it)

3. If you want a high quality deliverable, and you want to save labor costs, you can have a minimum number of people work on the task. But then the task will take more time because fewer people are working to complete it and live up to quality standards.

Keep adding components and objects and get faster each iteration.

4. If you want a high quality deliverable, and you want it done quickly, you can have several people work on it to complete it quickly. But then you have to pay labor costs for several people.
5. If you don't really care about the quality of the deliverable, you can assign a minimum number of people to work on the job and force them to complete on a short deadline. But the quality of the deliverable usually suffers (design limitations and bugs).

Armchair philosophy is so much easier than software development! :-)