Friday, May 13, 2011

Agile Development: A retrospective

Some thoughts I've had.
It helps keep things on track. The short iteration times, documentation, and emphasis on working "demos" at the end of each cycle means something can't get too out of hand.
I wish I had known about that evidence based scheduling towards the start. It really shows how to create good time estimates, even without the simulating you have info. Plus, it captured the whole idea of concrete "what needs to be coded in the next x hours" stuff that I think the system my team used missed
If you're going to introduce agile development, introduce it in multiple classes. A single semester gave me and my team a basic understanding, but a multi-semester learning process would have helped me learn it better and use it much better in this class.

You are a software gardener, not a software engineer

An interesting analogy I came across, with a bit of a rant, found here.
Some of the highlights:
Don't expect to know where every leaf will fall when you plant the seed.
Environment matters, both in where it's being designed and where it's being sold to.
Gardens will grow weeds. They are never "finished". They need to be maintained
The quality of the gardeners matters a great deal.

I think it's an interesting read. How true it is...well, that's something I'll only be able to tell with experience over the years.

Decorating, and Facades

The decorator design pattern is what we have seen as a wrapper class. Take some class, wrap an instance of it, and add some functionality. It's a form of delegation in the cases of the old class's functionality.
Facade design pattern is about putting forth a simple, common interface to several sub-systems.

Abstract Factories

The Abstract Factory pattern is an abstraction of creating related objects (such as subclasses of some abstract class) without having to directly specify what class. This is done by creating a static method (possibly within its own class) that uses some state to decide which type of object to return. By doing this and having the calling program influence this state, decision of which implementation can be put off until runtime.

Using SVN Repositories part 4: Merging and Reintegrating

Merging from Trunk to a Branch: So you've been working on your branch, and they've been working on the trunk. You want to merge their changes into your branch so it doesn't drift too far from the original. This is done with the merge command, which is used as "svn merge URL" where URL is the url of the trunk directory. Just like with updates (only more so), you have to resolve conflicts and make sure things didn't break your changes. Then you just commit, and it commits to your branch directory. SVN will even keep track of what was merged

Reintegrating your branch.
first, merge any changes from the trunk, test, and commit. Then, switch to the trunk. Reintegrating still uses the merge command, but this time from the branch directory and with the --reintegrate flag, which is needed because the branch is a combination of branch-specific updates and merges from the trunk. It tells SVN to just look at the differences between the HEAD of the branch and the trunk.As with merging in the other direction, you'll want to check nothing broke before committing the result.

That's all I'm going to cover in this mini-series of posts.
A more complete guide can be found here

Using SVN Repositories 3: Branching and Switching

This is a big one, and something I think would have been nice to see in earlier classes.

Why you want them: Simply put, to minimize disruption. Say you want to take a module out and add new features, and it would leave broken while you were working on it. Instead of creating that disruption, create a branch and work on the feature from there

As it turns out, branches are more or less copies, and in fact are made by making copies of the files and putting them in another area (usually done on the server because the way the files are represented letting it be much faster there). But they're SVN copies. That means that they share the revision history of everything before the split.

Quickly switching between branches:
The svn command makes a working copy reflect a different branch, as well as effectively running an update. so using it in the root directory of your working copy makes the updates and commits go to that branch, allowing you to quickly switch between multiple branches. Where it starts to get odd is that you can set different directories to different branches.

Using SVN Repositories part 2: Revision Keywords

Revision keywords:
These matter more if you're working from the command line although similar functionality is built into most GUI clients for places you use them. HEAD is the only one you'll be interested in when sending requests to the repository, and simply is the latest commit. The other three are used when looking at the working copy. BASE is the revision number of the local copy, COMMITTED refers to the last reversion number with a change to that file, and PREV is COMMITTED-1, referring to the version just before that change.