Ron Jeffries on Requirements

This is one of my favourite quotes on requirements:

Most of us were taught to write down all our requirements at the very beginning of the project. There are only three things wrong with this: “requirements,” “the very beginning,” and “all.” At the very beginning, we know less about our project than we’ll ever know again. This is the worst possible moment to be making firm decisions about what we “require.”

From Estimation is Evil, Ron Jeffries: Signatory of the Manifesto for Agile Software Development 

May Developer Challenge: Crush Your Achilles' Heel

Note: This was originally posted to the Dynamo Blog.

We all have it. It’s that gap in our knowledge that slows our development down. It’s your Achilles’ Heel. Every day we use the same tool, but we’re never really take the time to understand the fundamentals of how it works. This might be Git, SQL, or Regular Expressions. It might be a concept that we struggle with, but have never said, “OK, I need to dedicate some time to really understand this”. So this month, it’s time to crush it.

Inspired by RailsConf talk ”Nobody will Train You but You” from Zach Briggs, your challenge for the month of May is to identify a weakness in your development knowledge, and proactively train yourself in that area. Since the beginning of the year, I have been proactively addressing weakness in my development knowledge. Here are examples:

• SQL: After years of working with Rail’s ORM, ActiveRecord, I felt my knowledge of SQL beginning to wane. I went back to basics and completed Standford University’s course on databases. After this course, I had cleared out those SQL cobwebs, and back to feeling comfortable working at the SQL console again.
• NewRelic: Normally I use NewRelic in periods of stress, trying to resolve a performance issue. This means revisiting and learning the UI while I’m trying to solve a problem. By dedicating two afternoons to reading the documentation and reviewing a live application’s metrics, I feel much more prepared to dive in when there’s a performance fire.
• Performance Optimization: I’ve addressed performance in an ad-hoc manner in the past. To resolve this. I have dedicated time to review various resources on performance including the Scaling Rails series (which is developed a couple a few years ago, but still relevant). This resulted in a cheat sheet that I actively use to think about performance from day one.

But this challenge doesn’t end with passively reading a book or watching a screencast. It’s about reinforcing your knowledge by sharing with others. You really understand a topic, when you share it with others. So after spending the month learning, next month I encourage you to write a blog post, perform a workshop or write a test suite demonstrating what you have learnt.

So here’s the plan:

1. Take the week to identify your areas of weakness. As you go through your day, write down these areas as you experience them.
2. Pick an area at the end of the week to work on. At this point, you might want to consider how you will share your knowledge. Please share your topic in the comments below.
3. Develop a plan on how you’re going to improve your knowledge. Don’t try to be too ambitious, keep your goals realistic. Think SMART.
4. Work through your plan for the month.
5. At the end of this month commit to how you would like to share your knowledge. We will prepare to share our knowledge in the month of June.

OK, your Developer Challenge of the month of May has been issued! Please don’t forget to share your topic in the comments below. Good luck with crushing your Achilles’ Heel.