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! :-)
midrange.com
