The Art Of Software Development (part 2): Designing For Simplicity - Different Strokes, Different Folks
(Page 7 of 7 )

And that's about it. At this point, you, the developer, have enoughinformation to actually get down to writing the code, secure in theknowledge that you've successfully reduced the scope for changes ordeviations. This does not mean that changes or deviations will notoccur; however, as you'll see in the subsequent parts of this tutorial,you can reduce their impact on the overall development plan by managingthem carefully.

After reading the material above, you might be tempted to think thatthere's way too much paperwork involved in the pre-implementation phaseof a project. You're right - there is - but much of it is aimed atprotecting both you and your customer from creeping changes, andensuring that the final product is delivered in an efficient andcost-effective manner.

It should be clearly understood, also, that the processes outlined abovemay not work for every Web project. For smaller projects or teams, itmay not be practical to develop extensive documentation in the earlystages of pitching a project. However, an effort should be made toensure that requirements are formally captured and signed off on priorto development, and that there exists clear communication on thedeliverables between customer and vendor, so as to avoid problems at alater stage. Time should also be taken to have a clear process ofmanaging change requests, so that the overall development of the programis not unduly affected.

If you're interested in improving your design skills, here are a fewarticles you might find interesting:

The principles of good design, athttp://www.w3.org/DesignIssues/Principles.html

Jakob Nielsen's usability Web site, at http://www.useit.com/

Principles of user interface design, athttp://www.asktog.com/basics/firstPrinciples.html

An article on simplicity in software design, athttp://construx.com/stevemcc/ieeesoftware/bp06.htm

Quotes on simplicity in software design, athttp://www.vanderburg.org/soft-quotes.html

I hope you enjoyed this article, and that it gave you some insights andideas on how to manage your software development projects moreefficiently. In the next part of this article, I'll be spending time onthe third part of the development cycle - actual code development - andoffering some general tips and tricks on how you can simplify andstreamline the process to account for changes at a later date. See youthen!

Note: Examples are illustrative only, and are not meant for a productionenvironment. Melonfire provides no warranties or support for the sourcecode described in this article. YMMV!

DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.

Comments On: The Art Of Software Development (part 2): Designing For Simplicity

>>> Be the FIRST to comment on this article!