Design Twice, Code Once
Bad Excuses Related To Design
- The sooner we begin coding after contract award, the more
successful we are.
- The architecture will evolve over fifteen releases. This
is evolutionary development.
- We want a design from which 100 percent of the code can be
automatically generated by a CASE tool.
- Pseudo-code is design.
- You can't test the architecture until integration test.
- What is client/server network-capacity planning?
- Since none of our software engineers have ever done OO analysis
and design, we have scheduled two days of training to bring them
up the learning curve.
- We are doing OO design so our application can be
90 percent reuse of legacy software.
- We don't need a person experienced in this design method
because we are using a CASE tool.
- We have planned very little cost and schedule for design
because this application will be an integration of COTS and GOTS
software.
- We don't need a person experienced in designing a client/server
architecture because the network design will implement the architecture
described in the Defense Information Systems Agency (DISA) Technical
Architecture Framework for Information Management (TAFIM).
- We didn't waste time quantifying the future user load on
this network because this network was designed with more capacity
than we'll ever need.
- We won't know the high-frequency queries on the new database
until the database becomes operational. This is low risk because
we are using an industrial-strength DBMS.
- The cost savings are not in reuse of architecture; they are
in reuse of code.
- Our design is excellent because we devoted 10 percent of
schedule and 3 percent of cost to top-level and detailed designs.
- We don't have any time period during development dedicated
to design because our method is RAD and prototyping.
- Measuring design complexity is typical of the kind of idea
a technologist would come up with. We're software developers,
not technologists.
- I can't devote a lot of resources to worrying about the cost
of maintenance because I'm on a tight schedule.
- The components of the client/server network are hardware,
middleware, and operating system software, so the network should
be designed by systems engineers before the software developers
come on board.
- This is a war-fighting machine with lots of metal, so the
system architecture should be developed by hardware systems engineers
before the software developers come on board to start developing
the million-plus lines of code that will control this machine.
- We don't keep our design representation in the CASE tool
consistent with the source code. It is too hard to go back and
change the design in the CASE tool after code has been manually
added to the code that is automatically generated by the CASE
tool.
- We can't keep our design representation in the CASE tool
consistent with the source code because we can't prevent the
programmers from changing the source code automatically generated
by the CASE tool.
- Why should we develop our design around standard Application
Program Interfaces (APIs)? We're not going to be replacing software
components after we deliver this system.
- What is a standard API?
- We can't afford the additional cost of designing for reuse.
- Our design isolates persistent data from applications
by storing the data in a relational database. Business rules are coded in the application software because the programming language is more flexible than Structured Query Language (SQL).
- There is not enough time for design. We are driven by short
cycle time.
- Complexity management gives the theoreticians something to
write about, but this is the real world.
- If we put design under configuration control, the programmers
will quit.
- It is an OO design because it is programmed in C++ (Ada 95).
- We are complying with the good practice of using Ada by using
a code-translation tool that inputs FORTRAN and outputs Ada.
- We can't trace requirements from the system architecture
to software components because the system is partitioned into
functions and the software is partitioned into classes and objects.
- It is not a risk that no one on the development team has ever developed a large relational database. SQL is a 4GL that is very simple and easy to learn.
