Laws of Programming
Software Engineering in the real.
Bertrand du Castel, Austin, Texas
Amended May 20, 2009
# 1: Ignore the processAmended May 20, 2009
The process will constrain your mind, and you'll miss simple solutions.
#2: Do
Some do software engineering; some do engineer software.
#3: Design is worthless
It will crumble with the first line of code written.
#4: Let the computer think
A bad but running hypothesis is often better than a non-running hypothesis, as good as it is. Often the computer will show you why the hypothesis is bad, perhaps by crashing, perhaps by showing a bad result, perhaps with a garbled display. You'll learn faster this way, because that's also how our brain works.
#5: Trace, don't comment
A trace is a live comment, which has much better chance of staying current than a comment unattached to running code. Disallow the tracing when going commercial.
#6: Test
Keep the test alive, and build it as you build the program. When you'll be done, the test will be done, too. If you figure out how to do that with advanced human interfaces, let me know.
#7: Language doesn't matter
In a given generation, all languages are about equivalent. Don't worry about them. Common languages are good in that they get lots of web references.
#8: The web works for you
In most cases, you'll find the solution to your problem right there on the web. If not there, you'll learn enough by looking for the solution to then figure it out by yourself.
#9: Performance matters
Get performance from the start. Performance wins hearts.
#10: The human interface is worth the time
Human interface development is often lengthy and much more time-consuming than the function it serves. However, it's 80% of success.
#11: No defense
Defensive code adds complexity, slows down the program, and hampers its evolution. Some programs are slower than about any other with the same function; they are built with defensive code upon defensive code.
#12: Don't worry about the future
You don't know what the future holds. All the code you put in "just in case" for the future will just hinder that very future.
#13: Refactor
It's always tempting to build on ruins. It's also the fastest route to newer ruins. Refactor often.
#14: Show early
The sooner the better. Early feedback is the most valuable sort. You'll understand where you should really be going, and you'll build a constituency of interested parties.
#15: Always keep the code working
Make it do something right from the start, and keep it that way. You should always have working code, ready for you, ready for a demonstration, ready for the next improvement.
#16: Respect the politics
It's Conway's law, or Wall Street's "don't fight the tape." The organization does the politics. You do the programming.
#17: Documentation is failure
If the software is useful, you'll be asked to change it. If it's useless, you'll be asked to document it. I heard that a long time ago, I don't remember where from.
#18: Have a good design
That automatically ensues from following the laws of programming.
#19: Follow the process
You're done now. Time to get back into the ranks.
Dedicated to Stephen Whitley, architect extraordinaire.
All the opinions herein are mine only, not Schlumberger's, and I assume no liability with respect to the use of any information, product, process mentioned in this paper, or for damages resulting from that use.
If you have comments or rules to propose, please let me know at ducastel@slb.com.
Bertrand du Castel is Schlumberger Fellow. He received the 2005 Visionary Award of Card Technology Magazine for the Java card, with more than 5 billion sold. Bertrand is author with Tim Jurgensen of Computer Theology: Intelligent Design of the World Wide Web (Midori Press, 2008, ISBN: 978-09801821-1-8). Bertrand has an engineer diploma from Ecole Polytechnique and a PhD in theoretical computer science from the University of Paris.
Souvenir: Rosenbaum, Susan; and du Castel, Bertrand (April 1995). "Managing Software Reuse -- An Experience Report". 17th International Conference on Software Engineering, Seattle, Washington: Association for Computing Machinery.
© Bertrand du Castel, 2009. All Rights Reserved.



Comments
Write New Comment ▼
Write New Comment
Sorry! This knol's owner(s) have blocked you from editing, making suggestions, or commenting here.