The Rules of Software Development

Last year I was working at a large enterprise. Over the summer we had an intern join us, who I couldn't help but show the ropes. We managed to cover several rules of software development in just a few months. After the internship wrapped up, he was nice enough to forward the notes he took while on our team:

  1. Follow your heart
  2. Never volunteer for meetings, because then you become "The Guy"
  7. If all else fails, ask your neighbor
  9. If it's final, then it should be final
 13. Decision trees
 16. Always favor something that saves you 45 seconds
 22. Assertions should assert on something
 52. Monkey patching is for the zookeeper
 72. Always try to work in a place where there are palm trees
 82. Kernel panic is rarely good
 86. If you ever see a cool test, run!
 94. It's all slashes these days
 97. Agile doesn't work if you just hear things
186. Always use an attached keyboard
763. We were talking about splitting purchase orders, 
     they were talking about revision history, 
     now they're talking about splitting purchase orders 
     with revision history, and that's why agile works!

All the best, Michael! This advice will carry you far.

What Does My Agile Project Look Like?

When catching up with people many questions tend to revolve around my working situation. Curiosities including

• Do you have an office?
• Do you have a cubicle?
• How many people do you work with?

Ideal Workspaces

Pioneers of Agile software development tend to not believe in partitioning people off into different sections of a workspace. The big change from traditional techniques is that development needs to be more of a social, collaborative effort throughout the entire development lifecycle.

When we put people into different rooms, or even put up walls between them, they're less likely to talk to each other and know what is going on between them. This leads to a pain point much later on when we need to integrate the code of several developers. The solution is to have people in an open area and constantly talking as questions and ideas emerge. We all sit at a table with our computers, where it's very easy to yell out a massive design change or ask a question.

"We've just implemented flashscope, so no one should be attaching error messages to models anymore. Take a look at the HomeController for how to use it."

Realistic Workspaces

Part of the project in Los Angeles is Agile Coaching. This of course implies that the workspaces aren't currently set up ideally. We have a team room that fits about half the developers and the other half utilize cubicles in the adjacent room. It unsurprisingly presents some challenges, most problematic of which is easily the higher barriers to conversation.

We combat this in various ways, such as having a second 5-minute meeting (or stand-up meeting) midway through the day. Fortunately for us, we have just another week until we move into a team room large enough for us all.

Team Size

The development team I'm on is comrpised of four TWers and four client developers. Team sizes vary based on the scope of the project and finding that sweetspot isn't always an easy task. This probably goes without saying for every field, but there isn't a direct, linear relationship between people on a project and the amount of work that gets done. With software development, a team that is too large will have people stepping all over each others toes and will subsequently spend more time merging code than writing code.

The grads of my TWU class in Chicago are all on, or headed to, projects with two members to 54 members.