The Pond's Laws Home Page

This page will serve as a compendium of Pond’s Laws posts. The individual posts which promulgate the laws may be found as follows:

Pond's First through Tenth Laws
Pond's Eleventh Law
Pond's Twelfth Law
Pond's Thirteenth Law

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 aforementioned 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.

11. Whenever You Must Compromise, Try To Compromise the Schedule First. This is sometimes alternately stated as Slow Down, You’re Rushing Towards A Mistake. There will be times when the schedule is intractable as a practical matter. Those instances must be identified, and asking the question Can the schedule be compromised? is a means to that end. If the schedule can't be compromised, then you've still complied with this Law, because by asking the question, you tried to compromise the schedule.

Why don't I want to compromise scope? In most cases, cutting scope will invalidate your integration and test plans, because you’d no longer be changing code you thought you were going to change. Furthermore, if you’re going down this road, you’re already tired, you’re already behind and you’re probably approaching grumpiness as well, so your planning and analytical skills are going to suffer just when you would need them most.

12. Don’t practice in front of the CIO. A professional prepares ahead of time. Jimmy May says, “the time to learn to put out a fire isn’t when your home is burning down.” Different metaphor, same lesson. The oil company’s corporate headquarters was in a Los Angeles skyscraper; back in the ‘80s and ‘90s, I was part of the building’s Emergency Response Team for earthquakes and such. We practiced four times a year, and the LAFD told us we were pretty good for a bunch of desk jockeys. It was a point of pride for everyone on the team; none of us wanted to be unprepared if, heaven forbid, we were ever called upon to perform. We each had a clearly defined responsibility, and we regularly practiced our roles.

It should be the same with your datacenter’s “emergency response team.” They need to practice for things that you dearly wish won’t happen and take pride in their ability to address them.

13. Whatever change you’re contemplating, it won’t be any cheaper tomorrow. My primary project these days is the SIPA system I’ve discussed in this space several times before. My colleague Gerardo Saca van der Meden (who is going to be a superstar in this business, mark my words) and I spent the weekend thrashing through our complementary-but-not-entirely-aligned views of some design changes which we’ll be including in our next version.

At one point (when he erroneously thought he might lose our thoroughly professional “argument”), Saca wondered if we couldn’t possibly table the changes I was suggesting until after our pending release, in favor of spending our remaining cycles for this release building new features.

My primary concern with Saca’s suggestion was that it increased the scope-of-work of our redesign effort – the new features we build between now and then would have to be rebuilt in light of the redesign. This is neither good nor bad, it just is, and it needs to be given its due weight in the decision-making process. Is getting the features to market quickly worth the cost of the rework?

this copyrighted material was originally posted at https://blogs.technet.com/wardpond. 

the author and his employer are pleased to provide this content for you at that site, and via rss, free of charge and without advertising.

the author welcomes and appreciates links to and citations of his work. however, if you are viewing the full text of this article at any other website, be aware that its author does not endorse and is not compensated by any advertising or access fees you may be subjected to outside the original web and rss sites