Articles Feed

Ethical approach to Software Bugs

by: paul | April 8th, 2009 | 8 comments »

Software bugs are errors or omissions in the work we create. They are our mistakes as software developers. I am going to leave defining and dealing with bugs to a blog post I wrote last summer. I would like to take a closer look at software bugs, using an ethics metaphor to examine some of the rationale. For the sake of this blog, we fall into three camps: Software Utility, Software Relativism, and Software Craftsmanship.

Software Utility

“Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it.” -- Joel Spolsky

This is the camp of software utilitarianism. I understand applying this rubric in terms of return on investment might have J.S. Mill turning over in his grave, but there is a strong correlation here. According to wikipedia, utilitarianism “is the idea that the moral worth of an action is determined solely by its contribution to overall utility.”

Let’s take an example using Mr. Spolsky’s argument. We need to be able to quantify in dollars the value of Bug X. It is worth $1,000 to the company, because the ramifications of not fixing it means we only lose 2% of our user base. The cost of fixing this bug is $3,000 worth of development time. According to Software Utility, this is a no-brainer. Let the bug go, find something more important and more financially inviting to work on.

The problem here is there are so many unquantifiable variables in the equation. How do you put a dollar amount on instability? When someone tries to reuse the code that has a bug in it, you are spreading the bug throughout the system, literally, like a disease. You can deal with smaller known bugs now, or you can have them bubble up as diseases later on, where the price of fixing them will grow much higher. The software craftsmanship approach means you don’t have to get into the tricky business of quantifying everything.

Software Relativism

I have heard that, “my team doesn’t test drive their code, and so I don’t.” This is software relativism. Famous moral relativist J. L. Mackie “argu[ed] against the objective existence of right and wrong as intrinsically normative entities on fundamental grounds unsure what kinds of things such entities would be, if they existed.” In software, this is saying that whatever works, works.

Or, “We try to keep the bug list low.” Specific practices will be chosen due to their ease or convenience, rather than due to their inherent worth. If I join a team that is making money writing software without testing it, I shouldn’t judge, but do the same. There are no objective rights and wrongs, just a series of things that will work for specific circumstances.

One of the problems is when you get into a negative feedback loop. When everyone is sprinting for the finish line and there are no objective standards, you are going to end up with junk at the other end. We need a threshold of quality we will not fall below. Otherwise you will end up with a system of piecemeal quality, with parts that are stable and parts that are not stable. This is arguably worse than an unstable system. Either way, if becomes costly to maintain or just plain unmaintainable. The software craftsmanship approach avoids this problem of relativity by placing minimum objective standards.

Software Craftsmanship

I am calling the third section software craftsmanship because it fits conveniently in line with the software craftsmanship movement. It is based on the ethics of Immanuel Kant, specifically his first formulation of moral theory. It stated, “Always act according to that maxim whose universality as a law you can at the same time will.” The classic example is dealing with lying. Can lying for the sake of some other good be considered moral? Kant says to ask yourself: “If everyone lied, would the maxim still hold?” No, our society functions based on a presumption of honesty. Well, if everyone overlooked bugs or shipped with known bugs would the maxim still hold? No, software functions based on the presumption of quality. The user expects the software to work. To me, this means as an aspiring software craftsman, I can not ship with any known bugs. If you make lying acceptable, your neighbor will start to lock their doors. I am afraid that many software users have already locked their doors. So, a software craftsman can not live with bugs in their system.

I ship with no known bugs. As Thomas Jefferson says, “In matters of principle, stand like a rock; in matters of taste, swim with the current.” Shipping with no bugs and cleaning up my own messes is a matter of pride and principle. It can’t always be done with ease or convenience. Sometimes it means fixing some obscure feature you are sure no one will use.

Wake up and code!

by: paul | May 8th, 2008 | 1 comments »

The other day, I was with my team at an interview for an internship. After we had asked the candidate some questions, he started to reciprocate, asking each one of us a little about our development past. Every one of the developers stories went something like, I was at the wrong job, and had to get out. The candidate listened carefully to each story, sat for a minute, then asked the obvious perfect question, “What makes the right job?”

I heard responses like “Waking up in the morning and being excited to work, rather than counting the days until the weekend.” The reason this struck me as interesting was only when I reflected back to why I loved computers and programming in the beginning. It was all about the problem. I went to college, so I could join the CIA or some think tank which wrote software which monitored and defeated the enemies entire world. About every developer I went to college with got into computer science with some similar grandiose notion. Most of them were gamers that wanted to work on the next big game. Yet today, I know no developer who works on games, and I don’t work for a think tank. I know lots of developers who are more than qualified to do it, but choose not to. So, how does this relate to the right job question?

The answers about the right job question had nothing to do with the problem set being solved either. Nothing to do with WHAT applications were being written, but the culture and with whom they are being written. I think this is because each problem set worth application development proposes unique and interesting problems for a developer to solve. I have never been on a project which didn’t constantly keep me on my toes as far as problems to be solved. Even if the business domain is a bit bland, the development domain isn’t. I have seen developers to do lists get bigger and bigger from day one on a project, and never shrink. This has nothing to do with laziness, quite the opposite, it has to do with an insatiable drive to make things better than they are.

As a developer, my problem set isn’t the business/science problems I am solving, even though that might be interesting in itself. My problem set is development itself, the different patterns/practices I use to solve the world’s [software] problems. It is like many art forms where the beauty and creativity exists in the process of creation rather than the results. I am sure you could have asked Pablo Picasso to paint something he didn’t have any interest in, and he would have been passionate about it and done a wonderful job. I suspect it is because the importance is in the painting process and the choices you make during each step. How he chooses to depict the subject is more interesting more than the nature of the subject itself. I find the same true in development. The thought that goes into the different development choices I make on a daily basis is the part that drives me to love development.

Having the right results is only part of the equation (an essential part though). When I started my path as a developer craftsman, I learned the WHAT in applications is not as important as all the other variables. I suspect some of the other members on my team would agree, based on their answers to the right job question. Being part of a company that values the software for its own ends and spends the time and attention to do it right is a privilege to me. To me, that is the definition of the right job. I enjoy knowing my software will be used. Everything I write is valuable to the company for its longevity and success. It takes people who are similar in values for it to work, but it makes the work fun. It makes me wake up before my alarm, rather than snoozing.

Peer Pressure

by: paul | January 18th, 2008 | 1 comments »

One of the famous studies on peer pressure was the Stanford prison experiment. A group of average people were selected to play either a prisoner or prisoner guard. As the participant became engrossed in the role, the peer pressure from other participants quickly degraded their moral compass. The small negative actions lead the groups to quickly fall into patterns of behavior which were unlike their own.

I see peer pressure work in the same manner for good all the time. Since software is written by teams, the software is often a reflection of how well the team works together more so than individual skills of the developers. When you have a group of developers who entice each other to do good work, the outcome can be great work.

Creating a culture of positive peer pressure is about doing lots of little things. Small positive actions will lead the team to create positive patterns of behavior.

Here are different techniques which have worked for different teams I have been a member.

1. Name your team, not just your project. This gives me as a developer some self-identity as part of a team.

2. Greet your team mates each day. We shake hands to show respect each day for each team member. We generally start and finish each day with a handshake. This can alleviate tense situations by itself, as personal contact often does. No chance to avoid a team member.

3. Do some activity everyone enjoys. Anything from eating lunch together to playing a competitive game as a team. We have played basketball together. Being competitive with my team gives me pride in the team, win or loose. Get to know your team members.

4. We keep a good supply of coffee, tea, snacks, and gum for each other as gifts. This act of giving to the team promotes the selflessness any team needs from its members top succeed. There are different levels of skill on a team, but each team member is important. It is difficult to write software for any project of magnitude without the full contribution of each member of the team.

5. Switch pairs pairs often. When you work with everyone on the team, you feel closer to everyone on the team.

6. Talk while you pair. Reading someone’s mind takes more effort than talking. Talking aloud also is a great way of brainstorming. Pair communication starts when words become sound waves.

These small things can improve the accountability and creativity to make a well functioning team. A happier team will become a creative and productive team. A team that has a strong sense of togetherness will lift each other up when needed. I find myself more willing to step up to daily challenges with the support of the team on my side. There is no place for apathy and complacency in a team which has pressure to succeed.

When the team succeeds, as positive teams often do, it becomes a group success and brings the entire team great pride. A team which pressures each other to do better can turn an average developer into a great developer.

Shake Things Up

by: doug | July 19th, 2007 | 0 comments »

The most widespread and common greeting in the American culture is the handshake. Handshakes are shared between anyone meeting for the first time, to finalize a business deal, and to end a conversation. I spend a good deal of time around 2nd and 3rd generation Korean-Americans. In Korean culture, like many Asian cultures, the handshake is replaced by bowing. In these transitional immigrant generations, the bow and the handshake have been merged into one awkward action. I was recently walking through the reception line at the wedding of 2 second generation Korean-Americans and I went to greet the 1st generation parents. I was going to try to be respectful and offer a bow instead of a handshake, but just as I began to bend, a large hand was thrust out in front of me. I felt myself lucky that I didn’t end up with the guys finger in my nose.

One of the things I immediately noticed as I began working with the craftsmen at 8th Light is that everyday I walked into the office, every member of the team shook my hand. As each team member left for the day, he shook the hand of everyone who was left. I expect this on the first day, as you always shake hands with everyone on your first day. On the second day, I thought maybe they had all forgotten that they met me yesterday. As I realized that this would continue, It really made me start thinking.

As I went to work with another team for a little while I came to really miss the handshakes. I’d walk in the morning and maybe get an eyebrow flash from my teammates. A “Hello” would come if I was really lucky. I decided enough was enough, so I just started shaking hands. At first, I got some really weird looks and was left hanging a few times. The looks seem to ask “Why are you shaking my hand, we see each other every day.” But slowly it started to catch on. My teammates began to expect a handshake from me at the start and end of each day.

Here’s what I think these bookend handshakes do for a team. First, believe it or not, a handshake becomes an intimate gesture. It communicates genuine care and concern for each other. To me it’s a physical expression of the XP value of Humanity.

Second, it communicates respect. Sometimes design and project discussion can get very heated, especially if you are working with a passionate group of people. If your days begin and end with a handshake, everyday is bookended by a statement of mutual respect. There is a proverb that exhorts people to “Not let the sun go down on your anger.” That handshake is a way to let go any residual anger from the day and commit the next to dealing with each other with respect.

Third, It’s an honest statement about the hours you are working and the time you are putting in on the project. In a handshake-free environment, if I’ve had to leave the office early, I’d usually try to sneak out without anyone noticing. At the time I was in an office culture that promoted flexible hours, but you always felt like people were watching you to make sure you were still putting in your hours. I always put my time in, but because I sometimes played with my schedule quite a bit, I was always afraid that someone would perceive my time poorly. When an handshake begins and ends your day, you are being direct and up front about your time. You are communicating at the start of the day “I’m here, I’m ready to work” and at the end of the day “I’m gone, my day is over.” There are no apologies, no sneaking in or out, and no elaborate time-tracking system. Your teammates trust that you are working as much as you should be and you are not likely to try and cheat you company or your team out of your time week-to-week.

Try it in your team. It’s a morale boosting behavior that will cost a team nothing to implement, but will be one baby step to improving the strength and productivity of the team.

No really, we do that?

by: eric | June 5th, 2007 | 3 comments »

I’m a bit overdue on blogging, so in lieu of the normally brilliant and insightful commentary on the state of…er something… I usually put here I thought I’d share something that we at 8th Light have started doing.

Push-ups.

Every hour. Yes I realize it’s nuts, but look at a typical day for me. Wake up too late. Rush to get ready. Get distracted by something on the computer (today it was RubyCocoa). Realize that I won’t make it to the gym in time to lift weights. Work too late. Come home, eat, maybe help my future step-children with their homework. Suddenly it’s 10, and I haven’t worked out.

Aha - but I did 150 push-ups today. I think - I don’t actually count. Here’s how the 8th Light Fitness Plan (published Spring 2008) works. Every hour, on the hour, do push-ups. We started at 10 every hour and that was pretty hard once upon a time, now we’re up to 25. Well most of us. Today I saw two of the guys in another part of the building doing them, and I figure that if it caught on amongst 8th Light it can catch on elsewhere. After all we’re not that weird. Are we?

#####