I still remember a trip I took a few years backs to a furniture store that purported to sell "Amish" furniture. If you are unfamiliar with the Amish, they are a much caricatured religious group that disdains modern technologies such as electricity. The notion of the store is that Amish furniture is better since it is hand-made (although from the looks of it, the Amish people who made this furniture probably had a router table and some other pretty modern equipment, so I suppose that they meant Amish-style furniture or perhaps the furniture itself had been converted to follow the teachings of Jacob Amman). While I was browsing I overheard a curious conversation between a salesperson and one of the customers. The salesperson pulled out the drawer from a one-drawer oak writing table and showed the customer the high-quality dovetail joints on the rear drawer panel. He then spent about fifteen minutes explaining how great these joints were and how you just couldn't find that kind of attention (more)]]> http://www.journalhome.com/codecraft/20288/dovetailing-your-software-drawers.html http://www.journalhome.com/codecraft/20288/dovetailing-your-software-drawers.html Mon, 13 Feb 2006 13:44:00 +0000 Programming

Having worked at various levels in five startups and having observed a great deal more, I've come to believe that there is a very important tension that takes place within startups between idealism and opportunism. How well a company manages this balance is probably one of the single most important controllable factors in their long-term success. At its heart, the idealistic startup company is an idea company. To them it's about turning a certain idea into a reality and convincing people how great that idea is. In an idealistic company there is a lot of talk about the long-term vision and people focus on keeping things clean and simple and true to the core. People tend to think of Google and Apple as having been idealistic startups. An opportunistic startup sees a need and someone who will pay to fill that need and seizes the opportunity. Opportunistic companies focus very closely on what particular customers want; they listen carefully and meet the need as fully as they can. In an oppo(more)]]> http://www.journalhome.com/codecraft/17861/idealistic-opportunism.html http://www.journalhome.com/codecraft/17861/idealistic-opportunism.html Sat, 17 Dec 2005 15:49:00 +0000 Management

A couple of minutes ago one of the engineers came to me with a bug. Apparently the date parser can't agree about what timezone IST is. On some machines it appears to get Indian Standard Time and on others something like GMT+2:00 which seems likely to be Israeli Standard Time. Mug, Crug and Kublug I say. This whole timezone system is one big nightmare; we should throw out the whole messy business and fix the time problem at its source. From now on 2:00 means the same instant in time anywhere in the world. Wherever you live you'll adapt to the numbers. With that approach when someone in Chicago suggest a meeting at 5:00 with someone in Kathmandu there won't be any strange conversion, the person in Kathmandu will instantly know she's being asked to take a call in the middle of the night. Of course we'll get rid of 12 hour clocks at the same time so people won't mistakenly think that 12:00 AM is noon. We can move to military date ordering so sorting will never be a problem again as well 2005/(more)]]> http://www.journalhome.com/codecraft/17200/time-to-rant-about-time.html http://www.journalhome.com/codecraft/17200/time-to-rant-about-time.html Mon, 05 Dec 2005 14:14:00 +0000 I just got back from a week in the Maldives.  9 acres of palm trees surrounded by coral reefs teaming with fish and great food can do wonders for your outlook.  I thought for about ten seconds about trying to turn that experience into some kind of allegory for software and then realized what a ridiculous idea that would be.  Some laughable notion about keeping one's life balanced between work and family, maybe something about juggling glass balls or perhaps the sea as opportunity and the island safety, anyway I snapped out of it when I remembered that all the work I didn't do in the last week I now get to do this week PLUS the work I would have had to do this week anyway. 

So it's back to the same thing I do every night: trying to take over the world.  Oh, wait, wrong blog, it's back to the task of helping make the world a better place for software... Yeah, that's it.

So your good friend told you that he makes $150,000 a year, and you heard that Google pays $85,000 to fresh graduates. It's enough to make you want to find a new job and get mad at your boss for even offering a paltry $100,000 for your 10 years of hard-core experience, right... Well, right? Here's the funny thing about all these conversations, they are all basically BS. When you ask people how much they are making they lie. If they tell you without asking they lie. They lie on their credit card applications and they lie on their income taxes. Even people who are basically honest lie some of the time. To make things worse, stories grow. Let's say a friend of yours who graduated from MIT first in his class gets $80k right out of college (pretty darn good). Now you tell your other friend and so on and pretty soon a junior college grad is making $100,000 working as a tester.

More than once I've had employees come to me and tell me they have a friend at another company who is making S(more)]]> http://www.journalhome.com/codecraft/16643/your-friend-makes-less-than-you-think.html http://www.journalhome.com/codecraft/16643/your-friend-makes-less-than-you-think.html Fri, 25 Nov 2005 09:49:00 +0000

Lately I've noticed that ranting is taking up too much of my time. I suspect other people probably feel the same way, so to save all of us a little time and energy I've decided to maintain this page of reusable rants. The defining goal of this page is to collect general purpose rant templates that can be reused in emails, committee meetings, or blogs so that other people can save time having to think them up. Of course, these aren't proper rants either, they are more like building blocks to make creating a proper rant easier. All rants posted here are absolutely and 100% free and can be used without reference to me or any of the other contributors. That's right, its a page that contains software rants that cost nothing (as opposed to a series of rants about free software). This space is not governed by my usual blogging rules and I'll add to it any good rants posted in the comments section. If you post one, however, understand that your content is now free for people to use without citati(more)]]> http://www.journalhome.com/codecraft/16597/free-software-rants-page.html http://www.journalhome.com/codecraft/16597/free-software-rants-page.html Thu, 24 Nov 2005 13:02:00 +0000

Yesterday I had two literary experiences with nothing in common: I watched Harry Potter and the Goblet of Fire with my family and I read an article entitled What is Code in Free Software Magazine. With Harry Potter (the books, not the movies) I feel like Rowling has put together an insanely readable story that offers up its meaning at enough levels to satisfy everyone from an eight-year-old boy to a seventy-year-old woman. In short, it is almost as universal as Calvin and Hobbes. When I read What is Code my reaction was, "Holy Gotham, Batman; this looks like the work of the Riddler!" It was as though I had wandered into a barren cubist landscape where human language is ironically replaced by secret code words. I found myself wading through turns of phrase like, "epistemological dystopia" and bombarded with references to Heidegger (who(more)]]> http://www.journalhome.com/codecraft/16470/half-of-writing-code-is-writing.html http://www.journalhome.com/codecraft/16470/half-of-writing-code-is-writing.html Tue, 22 Nov 2005 14:37:00 +0000 Programming

Before I head off in to the weeds, let me get a couple of things straight: 1) I like unit testing, 2) I like agile, 3) I like getting enough sleep. With that said it's time for me to get something off my chest: I hate interaction-based unit testing and I think too much emphasis on unit tests is bad for quality!

For a while now I've had a basic coverage rule that governs how much unit testing is required from my team.  If it covers 85% of the lines of code in the class the class is covered. We have a nice nightly automation system that ensures it and we're allowed to arbitrarily tweak the % for particular packages or classes. I'm more or less happy with this threshold and if anything I think I'd probably choose to lower that number and not raise it. When I tell my hard-core agile friends about this and mention that I don't care if people write the tests before or after they write the code I get a bunch of snickering and a kind of "I suppose if you think that's good enough for(more)]]> http://www.journalhome.com/codecraft/16249/full-monty-tdd-and-political-correctness.html http://www.journalhome.com/codecraft/16249/full-monty-tdd-and-political-correctness.html Fri, 18 Nov 2005 16:27:00 +0000 Programming

A team of scientists at the prestigious Ritenokode University in Prague released startling new findings today that prove that the so called "software requirements" which have been a staple of high-energy coding theory for over forty years are not what we have believed them to be. While additional experimental verification is required, the findings are likely to change the way we think about software and some scientists are already hailing them as the most important discovery in coding theory since the discovery of NP completeness.

According to Dr Pike Ritchie, who led the research team, the discovery stems from a complex analysis involving measuring the speed-of-code against requirements. "For years we have believed that code moves through this theoretical space we called requirements and we would attempt to measure its speed through those requirements to compute the speed-of-code. What has always been a problem is that requirements never remain fixed, so our calculations were ne(more)]]> http://www.journalhome.com/codecraft/15901/scientists-prove-uncertainty-of-requirements.html http://www.journalhome.com/codecraft/15901/scientists-prove-uncertainty-of-requirements.html Wed, 16 Nov 2005 08:10:00 +0000 Humor

There are three main theories that I occasionally hear people expound for how to organize developers: 1) organize resources around technology layers, 2) organize resources around business areas, and 3) let everyone do everything. There are a number of fancy names for these approaches but they all escape me now. Actually my mind almost never remembers the names for things; it seems to just hook notions into my brain somewhere and then later when I need to discuss them with people or blog about them I usually have to look them up on the web, but I digress.

The first theory assumes that the complex thing is learning the technology skills and so you need only know about how the UI works or how the database works or how the middle-tier works, etc. You may still need to understand the whole of the business problem, but by having resources dedicated to a technology ring the feeling is that people can be more efficient. It is usually proposed by good business people or bad technologists.(more)]]> http://www.journalhome.com/codecraft/15583/three-theories-on-how-to-use-developers-efficiently.html http://www.journalhome.com/codecraft/15583/three-theories-on-how-to-use-developers-efficiently.html Tue, 15 Nov 2005 04:04:00 +0000 Management

All revolutionaries need a fashion line. Maybe it's a red headscarf or a black armband or a fez or maybe it's bell-bottom jeans, but there is some strange intangible need for each revolution to have it's own clothing to set it apart. The problem is that sometimes the only thing useful that comes out of the revolution IS the fashion.

Software, it seems, has also had its share of revolutions. Here are just a few (in no particular order): Client-Server, EDI, Dynamic Typing, Test Driven Development, Relational Databases, P-Code, HTML, Object Oriented Programing, CORBA, Service Oriented Architecture, XML...etc. Now only a few of these were big enough to actually achieve the status of being a revolution, most were more like movements or perhaps just trends.

Frankly, that's a lot of movements in the very short span of about 40 years and it's not even close to a complete list. Many of the so-called revolutions (like real revolutions) have actually made things worse for programmer(more)]]> http://www.journalhome.com/codecraft/15201/the-next-software-revolution-wears-black-leather.html http://www.journalhome.com/codecraft/15201/the-next-software-revolution-wears-black-leather.html Wed, 09 Nov 2005 08:51:00 +0000 Articles

I remember when builds took all night and my dad can tell me horror stories about the days going almost all the way back to wire-wrap computers (when build times were just that BUILD times), but with today's hard-core horsepower it seems like build and deployment times should be a complete non-issues. Nope, build times still matter for the very simple reason that code junkies can't wait. People think fast. When doing public speaking the challenge is to keep the audience attentive. The reason it's so hard is that the people listening are thinking WAY faster than you are speaking and as a result their attention can quickly find other things to focus on (like the spaghetti stain on your white shirt). This can even happen when reading and it certainly can happen while waiting for a build. As a point of fact I decided to write this blog entry while waiting for a full build and deployment of a J2EE system. Thankfully it is a JBoss deployment rather than a WLS or (God forbid) a WAS deployment. I(more)]]> http://www.journalhome.com/codecraft/14339/code-junkies-cant-wait.html http://www.journalhome.com/codecraft/14339/code-junkies-cant-wait.html Tue, 25 Oct 2005 04:35:00 +0100 Programming

The space shuttle is a great lesson for people about what NOT to do in engineering. Aside from violating every principle of KISS it basically asked all the wrong questions and as a result came to all the wrong conclusions. Consider reuse as an example. If you are going to make something more efficient by reuse the key question is where is it most important to save. With space launches the answer is so easy as to be trivial: the one thing you need to save is fuel. Fuel is the basic driver of cost for getting things in orbit. Always has been and until there are some major changes in technology (space elevator, anti-gravity, magic, whatever) it will continue to be. Now consider what the space shuttle did, it basically said the key thing we need to reuse is technology. These things are hard to build so let's just find a way to use them over and over again. All it cost them was... fuel.

Every time I saw a space shuttle coming down for a landing I thought to myself, "Wow, why are they (more)]]> http://www.journalhome.com/codecraft/14292/what-the-space-shuttle-taught-us-about-reuse.html http://www.journalhome.com/codecraft/14292/what-the-space-shuttle-taught-us-about-reuse.html Mon, 24 Oct 2005 14:03:00 +0100 Programming

Most of the people reading this may never be in charge of writing standards and thus be inclined to skip this post. Don't. These rules may be for the writer, but it's up to the user to ensure they are followed. If a standard is breaking a lot of these rules it's up to the people who adopt standards to choose NOT to adopt it. Remember IBM and Sun and Microsoft may be big, but the people writing code are a lot bigger and more powerful. Maintaining intellectual integrity is the best way to keep the worst instincts of the big guys in check. In short we need not use the processed bovine nutrient they dump out just because they dump it out. So, wielding the staff of Fiat granted me by my fathers of old I hereby and henceforth declare the following five rules for software standards.

The rule of size

"Any standard that cannot be written by three people over a period of three nights with suitable caffeinated beverage support should not be a standard. There is no limit on how (more)]]> http://www.journalhome.com/codecraft/14192/a-new-standard-for-standards.html http://www.journalhome.com/codecraft/14192/a-new-standard-for-standards.html Sat, 22 Oct 2005 17:47:00 +0100 Articles