digg

More People != More Progress
on March 25, 2008 @ 03:38 AM

There is a common misconception that the best way to add capacity to a project and reduce its completion date is simple—just throw more people at it. Although there is some truth in this, it is usually applied at the wrong times and it ends up having a very negative impact on the project.

This mindset that project development is a series of tasks and that somehow you can just throw people at them and everything will work out is foreign to me, because it won’t work out—at least not when it’s applied in haste.

Adding value to a project is more than completing tasks. Tasks are not isolated during project development. They are features which build on top of one another. Making good responsible decisions and understanding the code base both technically and conceptually goes a long way to help exploit easier and better ways of implementing features. This also helps keep the code base well factored, which in turn helps teams progress consistently and avoid creating a giant roadblock of technical debt which may have lurked just ahead.

0 comments | Filed Under: | read on

Agile Conference 2007, Day Four
on August 19, 2007 @ 01:39 AM

Day four was my last day at this year’s Agile Conference. I didn’t attend last year’s, but from what I gather from some coworkers I went with the schedule shifted a half day forward. In the morning I spent my time eating breakfast and listening to Uncle Bob and several other folks from Object Mentor carry on some interesting discussions. (This was not an official talk, I just happened to be eating where the OM team was hanging out.)

So on the fourth day I spent time at the following sessions:

Creating Change One “Tic Tac” at a Time

This session was very group oriented. Unlike some of the other sessions which involved roleplaying this session put about five to eight people at a table. The first goal was to discuss problem or obstacle that was overcome moving to some form of Agile practices. It could be a little win or a big win, but it had to be a win (Alistair and Jeffrey weren’t interested in the failures).

Each group had to vote and decide on a winning “win” for their group. Each “win” had to presented to the whole session audience. After everyone had heard all of the stories people were able to self-organize and go to the tables that had the “win” that they were interested in. Each table then had to discuss and list out the challenges and what led to them being overcome.

At the end Alistair and Jeffrey spent about 10 minutes going through some slides explaining the benefits of small tic tac changes rather then huge sweeping changes. They showed a nice graph which I haven’t been to find online yet. If anyone has a reference of it please send me a link.

What the graph portrayed was the effects of making changes and then benefiting from those changes. The idea is that for every change you make productivity goes down, and you stay in a dip and as you master the change your productivity goes back up and eventually surpasses your previous level of productivity. So this means:
  • the bigger the change, the deeper the dip and the longer the dip drags out
  • the smaller the change, the shallower the dip and the shorter you are able to surpass your old level of productivity

If you make a lot of small changes (one “tic tac”) at a time you end resulting getting a much higher level productivity in a shorter timeframe assuming each of your changes leads to better practices and higher efficiency. If you try to do too much you will be less productive then before and for a longer period of time. Alistair and Jeffrey believe that this is what causes so many teams who claim “Agile” failed for them.

Refactoring Databases : Evolutionary Database Design

Scott walked through the slides and Pramod did the real time demos. The “evolutionary” part of the discussion and probably their book, Refactoring Database – Evolutionary Database Design is more revolutionary to hard core DBAs who live a sheltered technical life which leads me to assume people from corporate america.

At the a technical level the presentation focused on:
  • incremental changes to the schema
  • versioning your database (rollback / roll forward features)
  • testing your data (verifying your setup data)
  • testing your interaction with the data (triggers, stored procedures, etc.)
  • use source control
  • developers should be able to check out and run a simple script which builds a development database for them
At a higher level the presentation focused on:
  • developers pairing with DBAs and vise versa
  • realizing that DBA is a different role, but not necessarily a different position
  • doing better database practices all around
  • communicating with the rest of the world

Scott has a lot of bundled up frustration with a developers, DBAs and “agile” people. He thinks there is too much of a barrier between developers and DBAs. He doesn’t like it when developers go around the DBAs because DBAs move too slow, although he recognizes that sometimes that’s just what you have to do. He seems somewhat ticked off about how “agile” developers focus on the practices during the application development, but that they slack when it comes to the database development. And this is going to get its own paragraph…

I agree with Scott when it comes to application development and database development. I think that too many developers consider the database a big dumb hash. At 40,000 feet I can agree with that analogy, but when you get closer to the ground the analogy stops working (with the current limitations of databases and disk storage mediums that we have today). Premature optimization is evil yes, but understanding SQL and how databases work isn’t premature optimization. Sometimes things that can be done in some simple SQL is more readable and faster to implement and test then the equivalent ruby or java code. Especially things which can be done with simple joins.

Back to the presentation…. Scott and Pramod are pushing for the same type of practices being used at the database level that are being used at the application level. Databases are archaic. SQL is archaic. It’s not elegant, but it’s still a very important piece to a lot of applications. Use the database when you should and test the hell out of what you’re doing. If you’re not using Ruby on Rails one of the best advantages of its framework is its builtin database migration tools. Thee are also plugins like Migration Test Helper which takes your testing of the database that much further.

After Refactoring Databases

I spent some time in the “Dungeon” where people were helping on creating a Rails web application for a non-profit group. I had some great discussion with Paul Pagel from 8th Light and also David Chelimsky who is one of developers for RSpec

0 comments | Filed Under: | read on

Agile Conference 2007, Day Three
on August 15, 2007 @ 10:56 PM

Today involved four sessions:

Clean Code 1: Cleaning Up A Mess

Uncle Bob delivered a great talk on cleaning up a mess. He asserts that developers want to go fast and that to the only way to go fast is to go well.

He uses a “dinner” analogy to clarify his points on messy code. The dinner analogy starts with a question, “What is the fastest way to prepare dinner?”. Regardless of ordering out or preparing it yourself, the fastest way is not do the dishes or cleanup afterwards. However, if you don’t do the dishes you are directly impeding your ability to quickly prepare dinner the next time.

There is much more to his talk, but you should really see it to experience it. I believe he’ll be at the GLSEC conference in west Michigan later this fall.

Clean Code 2: Craftsmanship and Professionalism

Uncle Bob’s second talk was more impressive to me then the first because it hit home a lot principles and practices that he views are required to be a professional developer and an agile developer.

While I’m not going to list all of them I would like to list a few:
  • Short iterations (short feedback loop)
  • Avoiding “solve everything” architectures (he calls them Turgid Viscous Architectures)
  • No Grand Redesign
  • Incremental improvement
  • TDD (minimal professionalism)
  • Code Coverage (strive for 100%)
  • Apprenticeship
  • and many more…

I really enjoyed one of his quotes on Grand Redesign:

Programmers like to make a huge mess and then bitch about it so they can make the next huge mess.

I haven’t read Uncle Bob’s books yet (real name Robert C. Martin) but that is going to change especially after I saw good reviews on a blog post from Guido van Rossum back in 2004.

Open Source Testing Tools to Support Agile Development/Testing

This talk just didn’t do it for me. It focused on every Java related. I’ve moved on from Java development, and what is happening in the Java world just isn’t very exciting (yes Groovy is nice). The presenter seems to know Java and everything associated with it very well. I think I just wasn’t the right type of audience.

It would have been nice if the talk was titled “Open Source Testing Tools to Support Java Development”.

Learning to Say “No”

This talk just didn’t do it for me either. The presenters did a lot of interaction and role playing with the audience on topics like saying “no” to your boss if he asks you to work late tonight, or this weekend. They gave useful ways to “preserve your self” and also work with whomever may be asking you to sacrifice personal time for their needs.

The techniques they show are useful, but most of it is common sense. This talk seems directly applicable to people who feel stuck in a corporate job who get taken advantage of, but don’t know the correct avenue to start breaking the cycle while keeping their job.

0 comments | Filed Under: | read on

Agile Conference 2007, Day Two
on August 15, 2007 @ 09:27 PM

Agile Conference 2007, Day Two

For the second day of Agile Conference 2007 I hit two sessions:

Agile Developer Practices for Dynamic Languages

This first session was alright. The presentation revolves around the presenter being well grounded in Java and its related technologies, and recently he has been moving towards dynamic languages. As he and his team are moving towards dynamic languages (he prefers Groovy and his non-present co-presenter preferred Ruby) they are realizing that a lot of design patterns, techniques and requirements of statically typed languages aren’t required, or are implemented completely different in dynamic languages.

The talk really focuses on showing people who understand things in java, but not in dynamic languages, that in fact you can do the same things (or in some cases you don’t need to do it at all) in a different way. He walked through things like:
  • dynamic builders (think Markaby or Haml in ruby) vs. using builder objects in java
  • you don’t really need factories like you do in java
  • delegation is much simpler then it is in java
  • DSLs are easier to write then in is in java
  • brief examples of “meta-programming” and that it sucks to do in java

Three people in the session couldn’t get over the fact that with dynamic languages you lose the ability to have auto-completion in your editors with the same level of granularity that you get with Java code and editors like IntelliJ or Eclipse. If their ability to productively program comes down to auto-completion or they think that auto-completion will hinder their ability to effectively solve problems I think there are bigger problems on there team.

The Crystal Methods

Alistair Cockburn a great speaker. He started out by focusing on how he believes people learn. According to Alistair people learn in three states: learn (shu), collect (ha), and invent/blend (ri). These stages directly correlate to the level of understanding and experience someone has in a particular area.

People start in the “shu” stage and learn with a clear set of instructions and/or rules. Next people move to the “ha” stage where they are able to apply the rules and they are able to understand that the rules aren’t necessarily giving them the best results. Here they start to experiment with edge/exception cases and they apply different rules. In the “ri” stage the person has moved beyond the instructions/rules.

Moving on from how people learn, Alistair presents Crystal as a collection of methodologies, and he believes that different methodologies are better suited for different types of contexts and number of people. Hence there are Crystal Clear, Crystal Yellow, Crystal Orange and Crystal Red.

He points out that Crystal methodologies won’t tell you how-to do something, they will merely tell you the properties that you need to have to be successful, and as a team he expects you to find the best ways to get there, although he does assert that certain key techniques (like Reflection, high visibility, etc) are key to implement Crystal methods.

Alistair’s background for coming up with Crystal Clear started back in the early 90s when he started traveling worldwide to to talk to different team about their projects. Through his years of experience he concludes that Crystal is made up of the good things that were common among all of them.

Alistair also believes that methodologies can be classified by a given genetic code. Here is the code for Crystal:
  • Mindset
  • Design priorities
  • Project priorities
  • Design principles
  • Key techniques
  • Samples
He also focuses on the seven properties of a successful project:
  • Frequent delivery
  • Reflective improvement
  • Close communication
  • Personal Safety
  • Focus
  • Easy access to expert users
  • Technical Environment
    • automated unit tests
    • automated acceptance tests
    • frequent commits and system integration

Crystal itself is based on the first three of these properties.

In the past I had read the Crystal Clear book and I have even implemented many of the properties and techniques in it so the session wasn’t completely new material, but I feel I was able to take away more from the session from having prior knowledge then if I were to come in with a blank slate.

0 comments | Filed Under: | read on

Agile Conference 2007, Day One
on August 14, 2007 @ 04:23 AM

Today’s the first day (or half day) of Agile Conference 2007. We’re into the wee hours of the early evening (8:46pm) and the social celebration (aka Ice Breaker) is underway. Whoever said geeks were asocial beings haven’t been to an Ice Breaker (or they didn’t serve enough beer).

I went to two sessions today.

The First Session

The first was on test driving the development of client/server application which was essentially a Shout/Echo server. It was written in ruby and the first half of the presentation was ok (I didn’t stay for the second half). The presenter drove the audience through a live coding session of implementing the server using test/unit.

I didn’t take too much away from this presentation. I know ruby, I know ruby’s socket library, I do TDD and I know test/unit very well. It was a good presentation overall and would be a good introduction for someone who perhaps wanted to learn ruby and/or TDD, or wanted to sharpen their skills on ruby’s socket library.

The Second Session

The second session was on Agile Myths. It was a collaborative and interactive session. The two presenters presented a list of 20 agile myths that they had heard while consulting. They also added in myths from the audience. After a quick high level overview of each myth they took out large manila folders and listed out each myth, and the audience formed groups of about five and every group picked a few myths.

The focus of each group was to either support the myth or debunk the myth, and they had to backup their claim. At the end each myth and supporting claim was discussed as a whole audience. This led to some very interesting discussions. After hearing opposing arguments on alot of the myths and claims I feel more confident being a true practitioner of agile methods.

Some of the myths that were debunked were:
  • Agile is all or nothing
  • Agile doesn’t produce documentation
  • Agile doesn’t commit to a deadline
  • Agile developers are just Cowboy programmers who don’t want to follow a process.

What agile myths have you heard?

0 comments | Filed Under: | read on