Programming with
a dose of satire.
Lifecycle
|
| ||||||||
 |
 |
|||||||
|
Lifecycle |
||
|
RULE 4: Design your software so that development, as well as run-time, is quick and scalable. During the development phase, quickness translates into programmers producing acceptable software development times, whilst scalability translates to an increase in programmers who will create marginally more software. During the runtime phase, quickness translates into hardware producing acceptable response times, whilst scalability translates to an increase in hardware that will support marginally more users. Programmers who are productive not only produce working software but are also able to produce it quickly. The ability for a developer to be productive is linked to how distant from the business the technology is. This distance means how much manual coding effort is required to translated business functionality to a working solution. A clear sign of inefficiency during development phase of a project is the emergence of a long hours culture. This shows that software development is based on the quantity of man hours and not the quality of the man hours. Where the distance from the business to the technology is greater more effort is spent writing code to fill this gap. The ability for a project to be more scalable is linked to where various aspects of the project lie in the quality-quantity dimension. The quality-quantity dimension measures repetitiveness, and therefore the ability to automate aspects of the project. Where a project is pure business function, for example a functional library, code automation tools couldn't be used. Where a project involves the persistence and editing of relational models code automation tools can create huge efficiencies. There is a general view that code automation creates a double benefit, of cheap labour and fast development times. This is not true. You should put your best quality people on code automation. If you put poor quality developers on code automation tools they will only end up creating poor designs. Design is at the core of any effort to maximise the efficiency and scalability on a project. On most projects there is generally technology at both ends of the project. The user interface at the front end and the data persistence at the back end both boil down to technical APIs. Having low level API's to express the business functionality makes it difficult to measure efficiency and scalability. This is why it is important that a business interface (or software) is built through the code base so it can be managed.
Talkback: Message Index:
The Messages: good pointsInteresting thing mentioned on http://www.martinfowler.com/articles/xp2002.html - all 50 states have to implement a child-welfare tracking system, giving us the opportunity to see the "same" system implemented 50 times. In Florida, a team of 100 people expected to deliver their implementation of this system in 8 years [starting 1990], though it is now to expected to deliver after 15 years [2005]. The budget is of course around $140 million over the original estimate of $32. In Minnesota, a team of 10 people implemented their system in less than 2 years [starting 1999], using 10 people. Total cost $1.1 million. These systems have the same federal requirements, but Minnesota probably focused on the "essential" requirements. quote: The comparison is a startling illustration of Chet Hendrickson's statement that "inside every large system there's a small system trying to get out". Keith Ray keithray at mac dot com Tue Jul 09 01:10:12 BST 2002
|
||
All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright © 1998-2007 Matt Stephens. ALL RIGHTS RESERVED.