13 Deadly Sins

The “Deadly Sins” from P. J. Brown’sWriting Interactive Compilers and Interpreters Wiley 1979.

–to code before you think.
–to assume the user has all the knowledge the compiler writer has.
–to not write proper documentation.
–to ignore language standards.
–to treat error diagnosis as an afterthought.
–to equate the unlikely with the impossible.
–to make the encoding of the compiler dependent on its data formats.
–to use numbers for objects that are not numbers.
–to pretend you are catering to everyone at the same time.
–to have no strategy for processing break-ins.
–(A break-in is when you interrupt an interactive compiler, and then possibly continue it later. This is meaningful in an environment in which the compiler is run dynamically, such as many LISP and some BASIC environments. It is not meaningful for typical uses of C/C++ (although there was at least one interactive C environment according to Chris Lattner).)
–to rate the beauty of mathematics above the usability of your compiler.
–to let any error go undetected.
–to leave users to find the errors in your compiler.

This entry comes to us from the GCC Wiki.

Some of My Favorite Rules

The website 1001 rules for my unborn son got me thinking about some of the rules I have for my life. Thought I would put down my own and list some of my favorite from 1001.

  • There is always time for a lemonade stand.
  • Perfect at least one recipe, steak doesn’t count.
  • Obstacles are ways of demonstrating our dedication.
  • Don’t complain, just work harder.
  • Take the new guy out to lunch.
  • Never swing at the first pitch.
  • Carry a pocket knife.
  • Learn from criticism.
  • X never, ever, ever makes the spot.
  • When excusing yourself from the table, you need not give a reason.
  • Stand up to bullies. You’ll only have to do it once.
  • Become an expert in something.
  • Never turn down a girl’s invitation to dance.
  • Order the local specialty.
  • Learn to drive a stick shift.
  • Never side against your brother in a fight.
  • Memorize the Bill of Rights and your favorite poem.
  • Keep your eye on the ball and follow through. In sports and in life.

189. Learn to drive a stick shift.

Never Forget Today

Human pain does not let go of its grip at one point in time. Rather, it works its way out of our consciousness over time. There is a season of sadness. A season of anger. A season of tranquility. A season of hope.

–Robert Veninga

I was on my way to work when I heard about the first plane.  I remember thinking it was probably an accident, like the plane impact on the Empire State building.  I passed by Tinker Air Force Base on the way; it was guarded but nothing too crazy.  The second  plan crashed into the second building and I remember thinking that we would be going to war with someone.  I called my wife and told her not to leave home.  Being a state employee they told us to go home ourselves.  Passed by Tinker again… there was a tank, several 50mm Brownings, and lots of concrete barricades.  I almost enlisted right there but they wouldn’t let any non-military traffic into the base (my wife didn’t find out about that till a couple years later… she was not happy.)

I got home, hugged my wife and daughter, and cried…

Chaos, with better lighting

We are time travelers. Moving through the universe forced to experience it through the lenses of history. Not simply limited to our memories; our very senses can experience only what has already happen, not what is currently happening. The clock for the whole of the universe it is measured by the speed of light (299,792,458 m/s) and while trivial, on our microscopical level, it is yet undeniable. The sun we look at is 8 minutes old, the stars hundreds (or millions) of years old.

The implication of this is nothing short of awe-inspiring. If we could instantly travel 2000 light years away from our planet (and had a telescope large enough pointed back at our planet) we could see Jesus walking the earth. In this way the universe has a memory more thorough and more complete than any computer or human has ever had. Nothing is forgotten, nothing is lost, nothing is missing; it is just getting harder and harder to put the picture back together in a way we would recognize it.

Make More Urgent the Necessity

Luck is the residue of design.

–Branch Rickey

After an Dr. Dobb’s interview with Christos Papadimitriou I have been thinking about design, creation, and development of complex systems.  Specifically systems that are fundamentally efficient.  The most important systems in existence are all amazingly complex (in fact, entirely too complex to ever design) and yet are built (often upon very simply concepts.)  They evolve into existence and are created without ever being engineered.

My favorite example is economics, which has as its basis very simple rules.  Economics sprout markets; which which are not only insanely complex but suffer from constant attempts to control always with perfect failure.  Other example include physics and the universe, computers and the internet.

So my question is, what other systems exist that can be created, but cannot be designed?

While I was Musing the Fire Burned.

There is pain, in this world, that once experienced leaves a permanent scar in our heart.  We are changed for as long as we live.  And though we walk through life, and laugh, and love; something of ourselves has been removed.

I believe, being Catholic, that when we talk about the peace of God; we are talking about that moment when God returns our hearts to the way they were before that pain.  To those who have experienced such suffering, that alone would be salvation.

Software Development
and Project Success

When I was growing up our family’s resources were less extensive than they are now, and as such, we sometimes had to do without some perks. One of these perks was a complete set of tools for home/car repair. Simple fixes like changing a battery would result in hours of work because of the inherit limitations of our tools; which ostensibly consisted of a hammer and a butter knife. Whenever I was brushing off the latest “injury” incurred while fixing something, my father would say to me, “Everything is simple if you have the right tool.” The better the tool is at doing a specific task, the easier it will be to complete that task. Ever watched “This Old House?” They had a tool to do everything! I didn’t even know they made adjustable-corner-rounded-cut-circular-door-saws with the optional digital level… cordless, if you are lucky. Heck, if I had a shop with 30 million dollars worth of specialized equipment, I bet even I could make something as fundamentally complex as a bar stool.

“Everything is simple if you have the right tool.”

This maxim (while not always true) is amazingly accurate in describing the modern development process. In fact, this is the reason I work on KDE (as opposed to the “other” Linux desktop environment.) Things are simply easier to do, are more productive, and more functional because the tool is designed better and focused specifically on desktop software development.

Today I ran into a series of articles by some application developers who I have come to respect. Their insight into the software development process will hopefully help give me some direction on future project management. Here they are will some selected quotes that stand out:

The strongest indication of a weak team is the realization that if you were to quit and start your own business, you wouldn’t try to poach any of your colleagues.

“Strong teams have almost impossibly high hiring standards. Strong teams will always leave a desk empty rather than settling for less than the best.”

“Examples of development hygiene include source code versioning, maintenance of an accurate bug or issue database, significant use of automated testing, continuous integration, and specifications that are kept current (whether incredibly detailed or high-level overviews).”

“A chicken is an individual who has significant authority over your project, but does not make a personal commitment to the success of the project.”

“And every time I’ve delivered software on schedule milestone after milestone, my influence and standing with stakeholders has grown. And every time I’ve missed a date, I’ve suffered, regardless of whether the late software was demonstrably better than what was originally planned for the missed date.”

“Documents such as specifications yield the same benefits of source control.”

“Discard all processes that are mechanically completed with little actual benefit. Tweak those that require more effort than necessary, maximizing the results while minimizing the effort.”

Umpire Effect

I overheard a discussion on NPR the other day that exemplified something that I have been thinking about. The discussion was a panel debate on last weeks news. The conversation inevitably centered around the war in Iraq and the current public opinion about the war.

A caller to the radio show (actually I think it was an email submission) made an articulate remark about the failure of the media to accurately report the successes the U.S. has had in Iraq. When the panel responded; they admitted that many military personal in Iraq make the exact same comment to them. Each of the panel members was a reporter of some type (the question of why expert panels are always filled with reporters and professors is left for another day) and as such each of them had heard this complaint a number of times in the past.

Then one panelist responded with the counter-point that “The problem is that I often hear the exact opposite remark; that if we (as reporters) had been more critical of the president when he made the case for war, we might not have ever gotten into Iraq.”

The problem with that statement is that its not the exact opposite remark (the opposite stance would be that the media doesn’t report enough about the current violence in Iraq.) In fact the two positions can actually be explained in relation to one another. People tend to “compensate” for their mistakes by making up for the short coming. Something of an enforced karma. It’s similar to when a baseball umpire makes a really bad call, realizes it as such, and then “compensates” for it by giving his next call to the infringed upon player/team; regardless of what the correct call should have been.

In some ways I think the media is trying to compensate for their own perceived failure to critically report on the argument for the war. The way they are “balancing” things out is by being overly critical of the success of the rebuilding effort. I don’t necessarily believe this umpire effect is intentional; but the evidence for it is pretty strong. While there is no doubt that the insurgency in Iraq is getting stronger, by almost any other measure things are getting much better there. Public projects are at an all time high, as is the number of completed project. Political involvement has steadily increased, oil revenue is up, the majority of law enforcement work is being done by Iraqis now, and GDP is steadily on the rise. What is more, the vast majority of Iraqis don’t want the U.S. to leave yet and think they are better off now then they were under Saddam (even if the really don’t like us.)

Because of the pathological nationalism that was rampant post 9/11 the media felt reluctant to criticize the President. Now that the President is unpopular it is much easier to be critical of him and the war he started. I guess that is really the point of this observation. More than I would like to believe the media is not simply a distributor of information but a reflection of our own prejudices. The umpire effect exists in the media (I have noticed it in a least a couple of other non-national news stories) because it exists among us. It is a way to make life (and baseball) a little more fair; as least from our point of view.

The Art of Hacking

Hackers and Painters is an essay by Paul Graham about “hacking” being more of a creative art than an actual science. Its is one of the best reads I have found online in a while. Originally seen at Slashdot.

To be fair and honest from the gate I must admit no not agreeing with many of the points that Paul makes in his essay. This is not really a concern to me because I, with very few exceptions, find fault with things everyone says.

What I find interesting about the article is how much rings true in my own experiences. Not that things that “ring true” make for a good evaluation of real truth. Communism appealed to so many people because it seem to do such a good job of explaining problems that they saw in their own world. But that being said…

My CS background was from a PhD is Mathematics who was bound and determined to convince us that software development was the physical extention of mathematics. I program by putting something down in code, trying to compile it, debug it, and see what happens. This does not jive well with the basic “workings” of mathematics, start with the known and move to extend from that. I, also, spent a lot of time feeling bad because I did not “know” theory.

Looking back over code I developed just a year ago; it becomes blazingly obvious that I am “working” on applications, not “solving” problems. My applications constantly change as my skill and style improve. During my freetime I work on applications because I love developing them, changing them, molding them, and seeing what the outcome becomes.

That being said, I spend most of my work hours architecting and designing. At work I am most assuredly a software engineer/architect (at least most of the time) from the standpoint of implementing changes and creating software designs. So maybe the answer is that software development is BOTH art and engineering. It can be, for hackers, something done to express and create while still being, for non-hackers, be a science used to discover and understand. Heck, most architects I know consider themselves artists and not engineers.