Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

SD Best Practices Day 4

Sign in to follow this  


There was a Day Four that I attended at the SD Best Practices Conference, even though I'm posting this a week later. As mentioned in the previous post, I wasn't entirely sure which sessions I would be attending that day, but these are the ones that made the cut:
  • Do the Right Things: Adapting Requirements Practices for Agile Projects by Ellen Gottesdiener - This session was probably good for people who either haven't lived through or studied some level of requirements derivation and analysis practices, but for me this was a painful session to sit through. Once I realized that the session wasn't going to offer anything new I probably should have moved on, but instead I think I pulled out my laptop and answered emails instead. The gist of the session was about techniques for eliciting, deriving, and analyzing requirements and balancing the techniques between agile processes and (let's call them) less agile processes. No new home run methods of requirements management - just a hefty overview of the different approaches out there. Like I said, if you haven't been exposed to these things it was probably a good session to attend. For me, I could have and probably should have spent my time elsewhere.

  • Scaling Agile Software Development by Scott Ambler - I like Ambler's style. He's a straight shooter and holds nothing back. As he calls it, he speaks in the real world, not some fantasy world. Anyway, in this session Ambler discussed the real world practices of agile techniques and compared it with the theoretical practices of agile techniques. In doing so he brought up a lot of statistics and misconceptions people have about agile, including claims like:

    1. Agile teams don't write documentation: They do. They may even write more documentation than other methodologies.
    2. Agile teams don't model: They do. They just don't try to model everything up front, due to iterations.
    3. Agile doesn't require planning: Wrong. Agile requires a lot of planning, and more importantly it requires a lot of discipline. Ambler argues that agile requires more discipline than any other software development methodology.
And of course there are others as well. Turns out Ambler is a great source of one-liners with quips like "Real professionals act in the real environment and not in a fantasy world of their own" and "Traditional development practices cover up a lack of discipline with paper trails". Regarding the statistics about agile, Ambler presented a lot of statistics collected from his DDJ Agile Adoption Survey 2008. Be sure to check that out for some very interesting numbers on both agile adoption and what agile techniques can actually do for you.
  • Clean Code II: Craftsmanship by Robert C. Martin - This session was a little difficult to take notes on. I think it's just Martin's presentation style. In fact, most of my notes are one-liner quotations. Even so, this was one of the better sessions I attended in that it really drove home the point that software development isn't about just your code or just your process or just your customer. It's about all three, and the reason software development is so difficult is because in order to do well you have to do well at all three. Martin believes in the KISS principle - Keep it Simple, Stupid. He believes that continuous refactoring is incredibly important, as much as iterative development is important. My impression is he thinks professionalism is lacking in the industry - I agree with him on that - and that software developers need an "attitude of cleanliness" with their code. An example is how a top notch chef constantly cleans their utensils while cooking. In the same manner, we should constantly clean our code while developing. At another point, he quipped, "How can you claim to be a professional if you check-in code and don't know that it works?" and the "mark of unprofessional behavior is to have a huge bug list". Amen.
In all, it was a great week at the SD Best Practices Conference. While I didn't learn anything outstandingly new, attending this conference helped connect a lot of dots and turn on a lot of lightbulbs in my head that reinvigorated my desire to do things better. I'd highly suggest this conference and SD West to anyone looking for better fundamental software development insight.

There's a few sessions that I have decent notes for that I'll be posting in the coming days.

Cross-posted at Code.Implant.
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!