Experience

I’ll admit that I got a mulligan. It was a Ruby on Rails project for an internal tool. I hadn’t worked with that technology stack much before. I kind of hacked something together based on the requirements, and it worked fine. There were few tests, and the design definitely did not use best practices. But it worked.

Next, I worked on a six-month-long Rails project using mostly TDD. After that, an opportunity arose to clean up the internal tool and add some features.

It felt really good. I felt like I knew the environment so much better, and could see where problems in the code could be easily solved using better Rails or Ruby techniques. It was quite exciting. At times, I was surprised that the code actually worked at all. I think that most developers rarely get this type of opportunity unless they are on a maintenance project, and I do think it was a valuable experience to see the aftermath of my own coding.

Synthesis

But afterwards I came to the realization that developers shouldn’t feel guilty about producing software. There are always going to be new technologies and practices to learn, tradeoffs to be made, and hindsight clearer than the present view. Should I refactor this class now or later? Should I make this easily extensible, or are we truly not going to need it? What should we work on first to reduce the technical risk on this project?

After every book I read on a subject, I learn new techniques and ways of thinking about problems. But this shouldn’t stop activity in the present. I will never have one hundred percent of the knowledge I need, and the solutions that I come up will only satisfice the problem.

I’m assuming that developers are really putting their best effort forth. This doesn’t absolve the developer from learning from their mistakes or preemptively learning.

I’m just trying to say that developers shouldn’t feel bad because they didn’t know enough to prevent every problem or solve every dilemma in the best way possible. Seeing mistakes in the past for what they are just indicates growth. Getting it right every time implies skill stagnation or perfection. Which one is more likely?

Have you had an experience where you wish you could go back and change something on a software project? A time when you read your own code and cringed? Where’s the balance between getting things right and getting things done? Consider leaving a comment!

Original article: Guilty Developer Syndrome

What is it?

The Pomodoro Technique is a system that Francesco Cirillo created and used when he was a student to help him focus. Staffan then used this technique successfully in software development, and believes that it can be applied to most things that people do. Pomodoro comes from the Italian word for tomato, which was the form of his original timer.

For the system, you just need a pen, paper, and a kitchen timer. I’m using this online stopwatch and using simple text documents to replace the pen and paper. The online stopwatch is nice because it has an alarm that rings through my headphones so I don’t bother anyone.

How do I use it?

So anyway, a pomodoro is a set period of 20 to 35 minutes in which you focus intently on the task at hand. After each pomodoro, you take a 3-5 minute break to stretch, relax, or just kind of space out. Nothing mentally challenging should be done. When you do four pomodoros back to back, it’s called a set. After each set, you should take a longer break (15-30 minutes.) This is an ideal time for lunch, running errands, making non-work related phone calls, etc.

The idea here is that the mind works best when single-dispatched, and that changing work habits to accommodate this reality increases effectiveness.

The more philosophical ramification is that instead of worrying about the passage of time (becoming), you simply work and record the activities. As Staffan says in a summary blog post:

Anxiety about not being done before some point of time is eliminated with Pomodoro Technique. One completed Pomodoro is the result. One more X marked next to the activity proves that I’m climbing higher. And the systematic reducing of interruptions gives me the opportunity to plan what used to be event driven actions.

I really think that this speaks to the sustainability of the work. Staffan noted that it reduces procrastination.

Before the pomodoro begins, you look at a list of tasks that you created at the beginning of the day and pick the best one to work on next. If you get distracted by an internal or external distraction, you need to 1) recognize and stop the distraction 2) write down the distraction so that you can reevaluate it at some point 3) get back to the pomodoro as quickly as possible.

Once a pomodoro begins, it must ring. This means that if you start working on something, you should work on it for the whole pomodoro. If you finish five minutes early, take the remaining five minutes and “overlearn” by ensuring you understand the solution completely. In the case of coding, perhaps you look over the comments to ensure that they make sense, or do some quick refactorings to make the code base more readable.

The first time I tried this, the internal distractions were quite numerous (“drink water”, “check bank balance”, etc.) However, once you can separate your desire from actually implementing the thing, your work goes a lot smoother. Really, this works with the Getting Things Done system by dumping things that seem important into another bin before actually dealing with them. However, if you don’t write down this distraction or review it in a timely manner, it keeps coming back. As David Allen would say with GTD, you need to keep the contract with yourself for it to be effective. But once you can file the distraction away, you are ready to get back to work!

Planning your day helps immensely to prioritize what you are working on. This is similar to sections of The 4-Hour Workweek that ask you “if you had a heart attack and could only work two hours today, what would you spend those two hours on and know that you had accomplished something significant?” When things come up during the day (which they invariably do), having a list of things that are important to you helps to put them in perspective. Moreover, by deferring things that are not really critical but merely seem that way, you allow yourself to get in a better rhythm. Ordering tickets to the show or emailing someone real quick might seem really important, but impedes your flow.

The system is simple, meaning that you get the maximum results for minimum overhead. The overhead in this case is winding up the timer and recording what you did. If you already track your time, the overhead is minuscule.

My thoughts

The greatest benefit to me is that instead of thinking in terms of fifteen minute or hour-long periods, I instead focus in terms of what I can do in twenty-five minutes. I think that this is a more natural time period and helps break tasks down a bit better, which helps with estimation. I haven’t gotten to the point where I have been able to estimate the tasks, but Staffan says that this is the next step. This makes sense, as it gives you feedback on how well you are estimating your tasks.

I also like seeing what my progress is like and where exactly I’m spending my time and doing a retrospective each day to see any personal process improvements. In a sense, the system is similar to the Personal Software Process promoted by SEI.

The hardest thing for me so far has been dealing with external distractions (other people. ) I shut off auto-alerts on emails. If there’s anything that can’t wait about twenty minutes, then that person should have called me or walked over. But it’s kind of tough when my manager walks over to chat about work. I can’t just say, “hey, come back in 16 minutes and I will have time for you.” So the result is a major interruption, which cannot be filed as a pomodoro (“a pomodoro is indivisible.”) I don’t have a solution other than to either seriously tell the important person to come back later or to just accept that there will be large but important interruptions at times and to optimize the whole by accepting them.

Part of my early success might lie in the fact that I have primarily been working in a non-team environment since I started the experiment. I found that often focusing for a few more minutes than I normally would have gives me additional insights and I solve the problem quicker. Moreover, taking a quick break helps to clear the mind. Often I see something in the first few minutes of the pomodoro that I missed at the end of the previous one. Staffan also suggests trying this for pairing, with similar results.

I think the real takeaway here is getting in the groove and not spreading your attention too thin. I think that this has been a large realization for me in the past year or so.

Mindmapping

Staffan also suggests mindmapping to more intuitively understand your day and to let the creative side of your brain work. Perhaps I will write more about that in the future, but here’s one that I created that I thought was representative and noncontroversial.

Original article: The Pomodoro Technique

Of the books that I have read recently, this one seemed to be a contentious one. I discussed this book with a friend who is in sales, and we came to completely different conclusions on the book’s premise. His idea was that the book contained a bunch of ways to manipulate people to get what you want, whereas I felt like the book provided methods to better understand, empathize, and work with people.

Throughout, Carnegie displays quite a bit of humor and wit, and gives memorable anecdotes to drive the points he makes home. Some things are trite on the outside, but they are quite useful once internalized. Here are some of the major points.

Carnegie starts out by talking about why he wrote this book. He had been searching for “a practical, working handbook on human relations,” but could not find anything. So he looked through history and tried to figure out how influential people in the past worked with the people in their lives, and wrote this book. Carnegie talks about research done that showed that “even in such technical lines as engineering, about 15 percent of one’s financial success is due to one’s technical knowledge and about 85 percent is due to skill in human engineering — to personality and the ability to lead people.” I thought this was interesting, and personally agreed.

The most important theme that Carnegie emphasizes is that no one thinks that they are wrong. Everyone, even a criminal, acts rationally based on his or her world model. Hence, criticizing people or arguing with them will only serve to harden their resolve and make them less likely to want to be around you. Seek to understand and empathize, and you can see where they are coming from.

The only way to get someone to change their ways or do something you want them to do is to have them want to do it. Giving honest and sincere appreciation and being “hearty in your praise and lavish in your approbation” are two great ways to show someone that you do like what they are doing. However, people have a great skill in seeing through baloney, so the praise you give must truly come from the heart.

Carnegie asserts that you must never complain. No one likes a complainer. He states that there is no better way to ruin a marriage than to constantly nag your partner. I can’t speak from experience, but that seems correct.

Avoid arguments and telling people they are wrong. If you must, do it constructively and explain how you have made the same mistake in the past and that it should be easy to correct. Good people aren’t going to mess things up on purpose. Sometimes it’s just a misunderstanding, and you should be quick to point out when you are or were wrong. If you are to point out shortcomings, call attention to people’s mistakes indirectly and in a private venue.

When someone has complaints, let them vent until they have nothing left to vent about. Show them that you care about their concerns and let them know what you are going to change to fix those concerns.

My friend in sales was somewhat right. There is importance in being able to sell, and this book can help do it well. Although you may not be in sales in the conventional sense, every day you are selling your ideas and opinions. Those who have good ideas and present them well are more respected, those that can’t fall by the wayside. You want to win people over to your ideas, and this book gives concrete ways of doing this.

Original article: Review: How to Win Friends And Influence People

“A tribe is a group of people connected to one another, connected to a leader, and connected to an idea.”

This book is self-described by Seth as a book that was supposed to be about leadership that happens to have a lot of marketing information, or a book about marketing that happens to have a lot of leadership information. The main point is that with the advent of tools to facilitate interactions between groups of people with common interests, being a leader is easier but even more important than ever. Tribes can be smaller and more precise because geographical limitations are mostly gone now. Apart from others’ need for leaders, being a leader increases your happiness because you are in control of your destiny and are constantly challenging yourself. Seth makes an even bigger point: we need YOU to be a leader, and there are huge benefits to be gained from doing this. Sometimes the going can be tough, but if everyone were doing it, then it wouldn’t be worth as much when someone provided true leadership. Godin emphasizes creating a movemen and working with it to allow it to thrive.

Seth makes a distinction between managers and leaders, stating that the former are risk-averse because they are trying to meet goals and are typically rooted in the “factory” mindset. The latter go against the status quo by having a vision and passion for what they are working for. Seth consistently describes these people as heretics because they have a vision and are willing to commit to that vision, challenging authority and old ways of doing things if necessary. Deciding to lead and not manage is a critical choice that you must make in your life.

Being a leader is not about talking. It’s about listening and sometimes even stepping out of the way so that your tribe is empowered. Seth is clear several times that if you are not passionate about what you are trying to do, you should not lead. Just sit this one out and wait until it is your time. But if you need to and want to, then you must step up. The only thing holding you back are your own fears.

One of my favorite parts of the book (not necessarily a revelation) is when Godin describes the safest thing being the riskiest, and the riskiest as being the safest. With the world as connected, fast-moving, and ever-changing as it is now, it is actually less risky to innovate and be proactive. There might have been a time when a large establishment or bureaucracy could have been seen as a positive, but now it’s seen as restrictive. But Seth is clear that organizations are critical to getting important things done in a timely manner.

Tribes is kind of like Who Moved My Cheese for grownups. Seth constantly talks about not settling and rising above the status quo. He warns about “what everyone knows.” Often the best innovations are created when people disregard what “everyone knows.”

Godin also discusses risks, whether real or perceived, associated with assuming a leadership role. In the end, it boils down to there being little true risk and a large possible upside. Most of the time risks are all in your head. People don’t start things because they are afraid of failure or of being criticized by others. However, Godin makes it clear than anything worth criticizing is worth doing. It would be much worse to do something and be ignored than to do something and have half of the people hate it. At least they are talking about what you did. To further show that most risks have little foundation, let’s say that you are leading a project and things go horribly wrong. More than likely you will not be fired for having a cause go awry, and you will definitely learn from the experience. In the event that you get let go, it must be easier to find a job knowing that you have been trying to innovate and change things up.

It’s not all about companies though. Seth talks about local leadership and non-profits, as he has been involved with working with those groups. Another nugget that I enjoyed was the discussion of faith and religion and how they parallel leadership and management. Indeed, leadership takes a great deal of belief in what you are striving for.

Seth makes the point several times that everyone is now a marketer, whether you think you are or not. You need to be able to sell, whether for your personal ideas or for your company. Jeff Atwood describes a nice analogy for seeing how more balance can increase your effectiveness. I listened to the Steve Yegge podcast that Atwood references, and I’m inclined to agree with his Yegge quote: “If there was one thing I could teach every engineer, it would be how to market.”

There are numerous concrete examples in the book, which makes internalizing the concepts easier. I highly recommend reading or listening. It definitely fired me up. There is a whole lot that I’m missing, you can see an outline that I created for Tribes.

I learned about this book when Seth put links to an audio recording of him reading the book available for free or nearly free in his blog. Seth practices what he preaches, so he asked me to pass this information along.

Original article: Review: Tribes

I highly recommend this book to anyone who has to negotiate with others. So basically — everyone. On a daily basis, you probably negotiate with your spouse, coworkers, landlords, potential employers, business owners, labor unions, and foreign governments. This book explains several principles of negotiation that are applicable to all of these relationships.

The book first discusses the problems of bargaining with positions, arguing that the optimal result rarely occurs because people dig themselves in and see the problem as a battle of wills. As an alternative, the book presents a method of approaching negotiating conflict from a few different perspectives. One part of the method is the ability to separate the people from the problem. In other words, being able to attack the problem with the other person instead of making the other person part of the problem is an important first step in successful negotiation. Another tenet is that one should focus on finding interests, both common and differing, that the parties involved have. Without understanding the interests that people have behind their stated positions, it is difficult to come up with agreements that are optimal. The book next focuses on methods of generating interesting solutions given the interests of the parties. Finally, the book goes into sections about when not to negotiate and how to avoid negotiation traps or pitfalls of a varied nature.

I can definitely see two reasons to read this book. One is for internal relations. Let’s say someone reviews your code and there are two differing opinions on how something should be implemented. Using the techniques of the book, you can get at the heart of the problem much easier. The other reason is for external relations. If you are discussing requirements or project scope with a client, there is invariably a form of negotiation going on. By being better able to understand the client’s interests, you are better able to provide value for them. The book has made me think quite a bit about listening to others’ perspectives before offering my own, and I find that the lessons are pretty universally applicable as well as understandable.

As usual, Wikipedia has an excellent outline of the main points, although you will get much more by reading the book as well.

Original article: Review: Getting to YES

One extremely positive effect that I saw with using this approach is that reviews become a lot easier. Let’s say that I take the old approach where everyone works on a huge monolithic task and then checks things in when they feel like it. Three developers might check things in before I get my changes incorporated, and if they changed files that I was working in, the reviewer of my code might see much more than just the changes that I have made. What’s more, by overloading the reviewer with the huge amount of code checked in as well as potential other changes, it’s more likely that the reviewer will miss something. The review will take longer, so when it comes back to me, it might be fuzzy in my mind.

I had the idea this weekend to limit my books in progress (BIP). I have a penchant for non-fiction books of all sorts, but recently started running into a problem where I keep adding books and never finish them. The problem lies in switching contexts. To really get what the author is saying, I have to skim through what I have already read and load it into my mind. After realizing that I could still remember the main arguments of books that I read in college but could not recall the points of the book I started reading last month, I started taking better notes and discussing the book with others to better synthesize the ideas contained. Methods for active reading have benefitted my comprehension of the material.

But even with these better notes, there is still time and effort wasted. Basically my efforts were too diffused to finish books in a timely manner, meaning that I get somewhat bored with the books. So my current plan is to create a queue with a BIP limit of about three to allow freedom in reading but to focus efforts. Then book reviews or writeups should be done shortly thereafter to use the knowledge gained from the book before it dissipates.

Hopefully these two thought patterns (WIP and BIP) were not very disjoint. The first inspired my thinking on the second. Although I suppose that both are instances of knowledge work, it’s interesting how ideas in one field can provoke ideas in a completely different area.

Original article: Limiting WIP and BIP

The first experience report probably had the most relevance to things that I have directly worked with. In the production Rails project that I worked on, we used Selenium for automated integration testing as verification of the development process. Dave Christiansen covered using Selenium to do automated integration testing on a Rails app. However, what was noteworthy to me about the approach that he took was that instead of writing and executing these tests only in the test phase of the development process, they were written and executed throughout the development lifecycle. He wrote a wrapper to generate RSpec tests from the Selenium IDE, refactored to DRY up the code, and then had the team write their own integration tests as they were developing. Since the tests were written in RSpec, they would actually be run whenever code was checked in (continuous integration.) After awhile, they built up enough helpers to stop really using Selenium at all except for replicating bugs.

This seems like a nice contrast to the approach that we took for two reasons. First, integration tests would automatically keep up with the development process because the team could run these tests within their own environment. If an integration test was broken, it would be immediately visible. Contrast that to having to rewrite tests several days after the structure changes for no apparent reason. Second, they ran a headless version of the Selenium Grid, which had the effect of getting their integration tests run in about five minutes. I remember this process taking quite a bit longer for us. Part of this was likely due to supporting IE6, IE7, and Firefox, but it seems like this still could have been sped up.

But overall, it’s nice to take the integration testing process and decentralize it. This might not work with all types of projects. Obviously having the developers in charge of their own integration tests seems like conflict of interest, but I suppose that solid reviews and other testing would reduce defects. But depending on the project, I can see that allowing the development and test stages to work more closely together is a plus.

Lunch was a nice experience, it was fun hearing about some things that people have done in the past and how that affected their current views on software development and testing.

Recurring themes

It seemed like people liked using Ruby for data munging and actual testing. Over half of the presentations given were using some form of Ruby for development, testing, or tools. You could probably get away with using Perl or something for this, but you can also probably pick up most of Ruby in a couple of days if you have used Perl before.

There was emphasis on abstracting tests to the largest degree possible to facilitate agility of development. This made a lot of sense to me, because one of the common pain points people expressed was having tests that were very brittle. When the application changed, the tests had to be scrapped. Considering testing to be a valuable software architecture practice in itself makes more sense than seeing testing as isolated.

Ideas and technologies

One interesting idea given in the “Open Season” part of each presentation was the idea of thumbnails for quick manual content tests. Instead of specifying a test that used screenshots or some sort of brittle method, instead print out an expected screenshot of each of the screens and the current screenshot on a single sheet of paper. Someone can then easily scan a whole page of these relatively quickly, as humans are naturally good at picking out differences between images and determining whether they are important or not.

Exploratory testing and pair testing were topics that were mentioned a few times, and I had never heard of them before. James Bach was suggested as a resource for this and pair testing. His site contains some newer articles that deal with these subjects.

Technologies discussed included:
Ruby and Ruby on Rails
Selenium
Watir
RSpec
soapUI
Groovy
Hammer/QTP

Overall thoughts

I really appreciated the constructive nature of the conference. Everyone was very knowledgable and had something to contribute to the process. All questions were asked kindly and there was a feeling of building on things others had said. There was a perceptible energy in the room during the concluding processes. People said that they were fired up to go to work on Monday and solve a problem that they had been facing using new approaches and technologies.

Something that stood out to me was the vast differences in terms that people had for testing practices. Obviously I am not an expert at testing, so there were some word hangups that I had. For example, the decision to call something a unit test versus an integration test was seemingly person-specific, if they used those terms at all. I can see how having a good stream of communication with team members, especially new ones, is very important in testing. Obviously this applies to software development in general.

While I have never been a dedicated tester before, I enjoyed the problems that people presented and their creative approaches to solving those problems. I think that I walked out of the conference having a lot more respect for software testers because of the challenges they expressed, both technical and organizationally.

One meme that I took away from this was the pirate heuristic: When you are out of ideas, steal someone else’s. I was out of ideas, and hence stole this one myself.

Original article: IWST Summary