Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 16:59:00 GMT)

Code Complete

Posted by Thu, 08 Jun 2006 15:11:00 GMT

8 comments Latest by Robby Russell Fri, 09 Jun 2006 15:44:12 GMT

I came across a review of Code Complete, 2nd Ed. last night… and saw the following quotes.

””People have already made all the mistakes that you’re making now, and unless you’re a glutton for punishment, you’ll prefer reading their books and avoiding their mistakes to inventing new versions of old problems.” “


””Once a programmer realizes that programming principles transcend the syntax of any specific language, the doors swing open to knowledge that truly makes a difference in quality and productivity.”“

I’m sold and with 900+ pages… I’m sure I have a few things to learn. I’m going to go pick it up shortly at Powell’s Technical. :-)

The Art of Delivery, part 1

Posted by Wed, 31 May 2006 04:09:00 GMT

1 comment Latest by David Rosebaugh Wed, 31 May 2006 19:52:02 GMT

Over the next few weeks, I am going to interact with the readers of my blog in a segment that I call… The Art of Delivery.

As a professional developer, my experience with working in development environments has been fairly unique each time. Up until PLANET ARGON, I had very little say in how we structured the very process that I was expected to follow. Granted, there is is a benefit to having leaders who have some good experience to help guide a team throughout the life span of a project, but a leader should also posses a sense of humility and stay agile in their processes. You cannot succeed in an environment where an old dog can’t learn new tricks. This sort of thinking reminds me of managers who feel that their sole responsibility is to manage people. People manage themselves, a leaders helps facilitate self-management. I’ll be the first to admit that I have much to learn in both areas. :-)


Earlier this year, the PLANET ARGON Core Team met to outline new processes. One hot topic was project communication and delivery. One of the areas that we all insist that we excel at is building better estimates and managing project delivery more efficiently. Every one on our team has their own ideas of how best to coordinate projects and we wanted to find a way to invent our own pattern… but what we realized is that we were borrowing a lot of ideas from books we’ve read as well as the lessons learned in previous environments. One of the things that we realized is that while we weren’t horrible at building estimates for a six month project… it was that we knew that the requirements of (almost) any project would change scope within six months. How could we accommodate new ideas in a project without disrupting the budget and the agreed timeline? We wanted to rethink this process and push ourselves to follow an iterative approach.

Focus on the now and then the then

Since then we have begun to define and redefine what each stage of a project looks like. How do we communicate stages of a project with our clients in a meaningful and clear way?

I’m now about to give away how we do business at PLANET ARGON.

Project(s), Release(s), Iteration(s), Task(s)

It’s not rocket science… and it shouldn’t be!

  • A project has many releases
  • A release has many iterations
  • An iteration has many tasks

What we do is isolate an iteration by collecting a set of goals to be accomplished that the client and we agree on as being of high value to the success of the project at this point in time. Tasks are essentially the individual steps needed to achieve those goals and we don’t go out of our way to list each one of those during an estimate process as some tasks take less time than it takes to generate an estimate for them. We include our developers in our estimate and specification process as they often have many great questions to send to the client to get further clarification. Often, much of this clarification process happens during a first iteration, which some call Iteration Zero... as no code is developed during this iteration. Prototypes, estimates, mockups, and Q&A is what iteration 1/zero consists of. This is that important design phase that people talk so much about. :-)

Let’s get back to thinking about delivery… and we’ll make the assumption that you’ve already worked out your estimates and are now ready to work on your (next) iteration.

Open Question: As developers, project managers, and curious readers… how do you proceed? be continued

The Daily Stand Up, part 2

Posted by Mon, 29 May 2006 15:11:00 GMT

4 comments Latest by Reagan Wed, 31 May 2006 03:29:40 GMT

In a previous post, I outlined how the PLANET ARGON team handles their communication of day-to-day work with the daily stand-up. Several people posted comments about similar processes and some suggestions were made to keep them from getting too stagnant. I wanted to highlight a few of those comments.

Aslak Hellesoy suggests, “Use a token – a rubber ball or something – for each person giving status. Only the person holding the token is allowed to talk.”
Florian Weber said, “Everybody standing up makes meetings go faster and more focus…”

However, not everybody is convinced…

Doug said, “I hate meetings, why on Earth would you punish your employees on a daily basis?”

Perhaps Doug has worked in environments that encourage too many bad meetings. A client recently said, “meetings are expensive” when we agreed to not have too many meetings throughout the project. Less meetings that are well-focused are much more valuable and productive. :-)

The one that caught my attention was the comment made by Aslak Hellesoy… he goes on to say, _“When a speaker is done, throw the token to a random person instead of just handing it to the left or right. This forces everyone to stay more alert, as noone knows who’s next.”

This got me thinking about how we had made it a ritual to stand in similar positions and I would start off the meeting. The team wasn’t too keen on throwing a ball around the room as we often hold coffee in our hand… so I came up with the following solution…. which reunites us with our little friends, the index cards!

Randomizing Daily Standup Meetings

Basically, all I did was take a stack of index cards and write a number on each one. Then at 9:15am PST, we all walk into the meeting room and take one. Whoever got #1 goes first and we work our way up from there. We’ve done this three times so far and most of the team seems cool with it. I’ll keep you posted as we solidify our approach to The Daily Stand-up.

...and of course… this comment also reaffirmed our decisions to do daily stand-ups…

Kevin Rutherford said, “Cool. And by “inventing” the idea yourselves, I guess you have much greater buy-in too?”

Related Posts

The Daily Stand Up

Posted by Tue, 23 May 2006 03:57:00 GMT

12 comments Latest by Scott Berkun Tue, 22 Aug 2006 02:17:19 GMT

I’ll admit it. I’ve never read a book that outlines that SCRUM process in detail but do have a copy of The Art of Project Management by Scott Berkun. In chapter ten, Berkun points out the purpose of having meetings as well as the annoyances that surround them. Over the past six months, we have toyed around with a few different approaches to holding meetings. There was a short period of time where we really weren’t sure what the best way to get company-wide information to everyone without boring them to death once a month or week.

A few months ago we tried something totally crazy… daily meetings! It caught on rather well.

There is one rule though, nobody can sit down. :-)

We hold a meeting every day at the same time and do not make any exceptions. Well, I will admit that we’ve missed two or three in the past several months but overall, we’re very good at keeping to the schedule.

So, how does this process work?

Each morning, I spend about 15 minutes preparing for a 10 minute meeting… which also is how I build my list for the day. This list appears on an index card as I keep it with me throughout the whole day. I also keep the previous and next days card with me so that I can make sure that things that didn’t get done yesterday get done today or tomorrow. Some of these tasks end up on BaseCamp or just get checked off as I complete the task.

Each morning at 9:15 AM PST (now you know where we are when we aren’t working or on IRC), we meet in our conference room and stand in something that looks similar to a circle. I wait until everybody finds their way into the conference room and then say, “Good morning!” I then do go over the following things (and use my index cards to keep me on topic)...

  • What did I do yesterday (or Friday/weekend)?
  • What will I do today?

Then the person who decided to stand next to me follows and we do this around the room… I think the order this morning was:

  • Robby
  • Jeremy
  • Brian
  • Jason
  • David
  • Allison

This is a good time to also bring up any thing that might be useful for everyone to hear… such as, “we got a new development contract signed yesterday!” or “client x will be on-site at 1:30 PM.” Along with this, we’re able to ask questions about other peoples work and act as a sanity check. Why the stand up? Nobody likes to just stand around for too long… when you stand up you avoid getting too comfortable and people are more likely to stay on topic and focused.

The meetings typically last 10-15 minutes and if you’re not doing something like this with your team… how do you cope on a daily basis?

Small Is Beautiful

Posted by Mon, 22 May 2006 10:20:00 GMT

5 comments Latest by Shane Vitarana Tue, 06 Jun 2006 19:07:53 GMT

Some people have habits that are hard to break. Mine is that I tend to pick up books off of our bookshelf…okay…90% of the books are my fiances… but I’ll take one and just open it and start reading. The problem with this is that I really don’t make (or find) enough time to start at the beginning and finish each book. I often end up just opening up to a random section and reading a few pages until I realize that I’m totally lost or until I find something interesting to think more about. Occasionally… I finish the book.

One such book that I am reading is Small is Beautiful by E.F. Schumacher, which was written in 1973. The topic of the book? “Economics as if People Mattered.”

The other day I read a section about developing nations, which has always been a topic of interest to me. I’m going to take a step away from the topic of the book and extract something that the author said that caught my interest.

“We tend to think of development, not in terms of evolution, but in terms of creation.”

When I read this… I know that this isn’t referencing application development but development of third-world nations… however it got me thinking. Is it our tendency to try and plan things the whole way through so that we can follow through and create the definitive and ideal solution in one try? This is exactly how some development processes work. Gather requirements, develop one monolithic plan, and implement it. This process can take a half of a year to several… depending on the size of the company. Perhaps there is very little difference between the three year project and the three month, except the smaller team and lapse of time. Could it be that when we admit that we know that requirements will change over time and if we take an iterative approach that we will be better prepared and more open to change?

...and perhaps the following quote could be applied to the topic of good usability...

“An entirely new system of thought is needed, a system based on attention to people, and not primarily attention to goods. . . .” - E.F. Schumacher

Development should be an evolutionary process… and real people should be where we focus our attention to.

...what are your thoughts?

Project Borat, an introduction

Posted by Wed, 03 May 2006 20:46:00 GMT

7 comments Latest by Joe Grossberg Wed, 07 Jun 2006 19:56:03 GMT

This is going to be really exciting and a fun challenge for our team. Over the next few months we are going to take you, our audience, deep inside the heart of a real development project. We’re going to be writing about our whole process from the moment the contract was signed until we launch the first public version of the application. As a team, we will be blogging about our various roles in the project and as we keep do our best to blog the process, we’ll be interested in hearing your thoughts on our processes and be honest about the lessons we learn ourselves.

The Project

Peat Bakke, the Project Director at PLANET ARGON and I have been talking to a new client about their new project. We’ve come to an agreement with them, which gives us permission to blog about our experiences, but cannot give details about the business plan, logic, or other secret ingredients that they have up their sleeve that will make their product successful. What we can blog about it… is our experiences and processes. Throughout the course of the project, we will refer to this project as… PROJECT BORAT. don’t ask… (see Peat’s blog for details)

The Sales Process

Each client that we sign a contract with is unique. We have yet to have the same things happen twice when it comes to signing a custom development or consulting project. We met with The Client a few weeks ago after Jeremy and I returned from Canada on Rails. While in Vancouver, one of three individuals that make up the core team of The Client had gone to CoR to learn more about the Rails community and had approached me to discuss the PLANET ARGON development process. Little did I know that the next week, I would be signing an NDA with him and his colleagues in our office in downtown Portland, Oregon. After signing the NDA, The Client outlined their great product idea and Peat and I listened in and asked them some vital questions:

  • Why Ruby on Rails for the project? (how familiar are they, what attracted them to Rails?)
  • How will the project make you money? (always an important question… and they are usually happy to discuss)
  • What is your ideal deadline for delivery of the project? (aside from the common answer of ASAP that we often hear)
  • Do you have a set budget for the project? (qualifying question to avoid any surprises)
  • How soon are you looking to make a decision? (helps us prioritize our potentials)

We talked with The Client a while longer and off they went with our business cards. Peat and I then scheduled a time to go over our meeting notes and pair on an initial estimate for the first few iterations. The first two iterations would include a specification phase, which includes pairing with the client (something we can easily suggest when they are local) to gather project requirements, paper prototyping, Use Case defining, and estimates for the first few iterations of architecting, development, documentation, testing, and delivery.

We went back and forth over a few details, scheduling, and have since signed a contract to begin the first iterations of the project.

...and this is where I direct you to read the next installment of Project Borat... with your host, Peat Bakke.

UPDATE Read my next installment, Prototypes Are Your Friends.

Older posts: 1 ... 10 11 12 13