Pond's Laws of System Design (or, How To Be A Competent Professional In An Irrational World)
I first promised this list in December, and at long last here is its current state. Hopefully you will find both humor and technical merit in..
Pond's Laws of System Design
(or, How To Be A Competent Professional In An Irrational World)
1. This list is perpetually a work in progress. It is never complete. No, this is not because it parallels my perception of how software development processes work. It's because the longer I'm in this business (28.75 years and counting), the more I find I can always learn something if I pay enough attention. Far less often than I'd like, I learn something important enough to merit a new law. When that happens, there must be room for it. ****
2. All user input is inherently evil and never to be trusted.
We are irresponsible if we don't design our systems to be secure. This has implications far beyond the obvious, so numerous and so profound that entire industries have been spawned around them. So, rather than reinforcing the existing (and highly appropriate) security consciousness, the purpose of this law is to remind me to secure the channels I mean to leave open as well as those I don't. This has numerous practical implications at every logical and physical tier of a networked computing system. For the SQL Server developer, the primary thing to keep in mind is we should never run native T-SQL syntax over a networked connection. Our interface should consist entirely of stored procedure calls with parameter sets, and the parameters that are passed should never be used in the construction of dynamic SQL. There are shockingly simple ways to hack into systems which employ these techniques, so it's a gold-star best practice to avoid them as described here. ****
3. When it comes to your work product, respect your ignorance.
Do we have a spec for our project? If we don't, how do we know what the scope of our work is? If we've got a spec, are we confident that it's accurate? Were the proper people interviewed? Were the proper people doing the interviewing? Has anything in the business environment changed since the interviews were conducted? Unless our shop employs a rigorous process such as Agile or TSP, experience suggests that extreme confidence in our spec might be the result of wishful thinking brought on by reduced expectations. There are lots of organizations that understand the value of the specification process and sponsor it appropriately; if you're lucky enough to work at one of those places, this issue will be an infrequent concern. Unfortunately, there are many more that don't understand it, and so cut some corners here. In this particular "pay-me-now or pay-me-later" scenario, electing to defer this payment is penny-wise and pound-foolish. Be open and honest about the state of our spec; if it's wrong and we don't have the time or resources to make it right, adjust your estimates accordingly. ****
4. You don't know everything.
Every hot shot developer under the sun can always learn something. If that wasn't true, there would be no need for Law Number 1. ****
5. Find a niche that you and others can derive value from and develop a high level of competence. Rinse and repeat.
This should be pretty simple. The more "little things" you're good at, the more value you bring to your customers. This goes triple for big things. It also goes triple for the value that the job brings you, because when you're demonstrably good at little things (and big things), your confidence and competence grow, and the building blocks are in place that will enable you to learn new things. ****
6. "Play" with your product.
Give yourself time to experiment. Some of the most amazing insights I've had come from thinking outside my comfort zone. A small example from my first DBA position: I wrote a one-statement data conversion query on our then-blazingly fast dual 100mHz Pentium UNIX system. The query was poetic in its beauty; triple nested subselects with correlated sub-queries. Truly demented. I kicked it off at 6pm on a Friday night, and after a three-day weekend returned on Tuesday morning at 6am to find it still running. I killed the query and re-wrote it as three far more mundane (but not unformidible) statements, which produced the desired results in eight minutes. Which led directly to the insight that.. ****
7. Random elegance that doesn't serve performance and maintainability is no virtue.
This is also sometimes stated as, Good enough is good enough. The eight-minute query above was only going to be run once. There were probably ways available to get it to run faster, but this law suggests that eight minutes is fine for a one-time query. Similarly, say we're working on a tight schedule. You've got two transactions, each with a 200ms SLA. spTranA is running at 160ms but you think you can get it to 40ms; spTranB is running at 210ms but you think you can get it to 150ms. Assuming that both transactions are run roughly the same number of times, this law suggests you should work on spTranB first. Even though you can have more impact on spTranA, that transaction is already within its SLA -- it's good enough. spTranB needs the help more, even though the pure magnitude of the impact of your work there will be smaller. ****
8. Know yourself.
No human can be all things to all people. There are things you're good at and things you're not. Know them, be honest about them, and work to improve where you need to. ****
9. Don't confuse speed with infallibility.
When they're working right, computers are so fast and so good at what they do that it might be easy to think they're perfect. They're not; indeed, they can't be. They were built and configured by people, who make mistakes. One night we were moving hardware around in a machine room. The afforementioned dual Pentium UNIX box had an external RAID array on it. The hour grew late, and since I lived almost 100 miles from the office, they let me go home with promises that they'd put the box back and call me when it was done. Well, 20 minutes after I got home I got a panicked call from the Ops guys -- the box wasn't recognizing the RAID array. We spent an hour running every diagnostic under the sun; we went to bed with the understanding that I'd be in at 5 (which meant getting up at 3) to fix the problem -- although how, I had no idea. That night, I dreamt the scene from "The Andromeda Strain" where the team doesn't get the emergency message because a piece of paper lodged between the alarm bell and the striker. Sure enough, when I got to work the next morning, I found that somewhere in the seven feet between the counter where I'd left it and its ultimate destination, someone had bumped a rocker switch on the back of the array and changed its SCSI address. Putting it back solved the problem. I have plenty of stories like this, both hardware and software related. Weird stuff happens. Be open to it before you start tearing your hair out. ****
10. Your code is a communication with someone else, who will likely come after you are gone.
Do you plan to stay in your job forever? If so, then this point still applies for you, because, unless you own the business, you've got to take your boss's plans into account as well. Your code should be professional in all aspects -- properly blocked, properly commented, and unduly esoteric only when necessary for performance or unavoidable for functionality (and, of course, extensively commented in either case). Things which appear simple to you because you wrote the code may appear anything but to someone who follows in your footsteps. If we don't deliver our customers a system that can be maintained by another competent professional, then we have not delivered full value.
More to come..
-wp
Comments
Anonymous
January 01, 2003
A colleague sent along an email earlier today which, at its root, strikes me as a plea for Pond's SeventhAnonymous
January 01, 2003
Welcome to installation #118 of Log Buffer , the weekly review of database blogs. Today, we’re gonnaAnonymous
January 01, 2003
If you've worked with databases long enough, you develop a set of truisms that you carry around in your...Anonymous
January 01, 2003
Marc left a great question on a Pond's Laws post from July of 2006 : Hi, I have a flashcard system thatAnonymous
January 01, 2003
In my eternal effort to keep up with everything, or at least the things related to what I do... ...Anonymous
January 01, 2003
Egad, a technical post! And after I'd already said goodbye for the month. A long time ago, a friend taughtAnonymous
January 01, 2003
Our blogging site is going to go dark in an hour or so for a software upgrade, so I won't be able to...Anonymous
January 01, 2003
Another reference to Pond's Laws comes to light from an exchange on an internal SQL Server discussion...Anonymous
January 01, 2003
When I first published Pond’s Laws, I promised it would be a living document. Herewith is the first evidence.Anonymous
January 01, 2003
I had a couple of extra minutes today and found this post on Linchi Shea’s blog ; I wanted to commendAnonymous
March 12, 2014
I bumped into a reference to this list on stack overflow. Very well done, and thank you!