Silver Stripe Blog

One of the dangers of developing an application is assuming that all your users are just like you.

Case in point: The Silver Catalyst tool that I am currently developing.

Imagine for a second that your team is using Silver Catalyst. They have entered all the data into the tool and are using it regularly. At the end of the week, an executive asks for the status. Because Silver Catalyst is a web app, the PM figures that the executive can just login to the tool anytime they want the status, and therefore creates a login for him. A couple of days pass and the executive asks for the report again.

Guess what? The executive never logged into the system! The PM is now back to taking data from the tool and preparing a report.

Continue reading ‘Usage patterns, or why you need to support alternate modes of interaction’ »

A big update. The latest version of Silver Catalyst was released on Tuesday, and it has a brand new plugin feature. This is a big feature for the version one release — which is right around the corner — because it means that Silver Catalyst becomes extensible in the future.

Along with the plugin support, the release contained the first plugin: PDF Report. With PDF Report, you can download a PDF version of the dashboard data. Why is this cool? Because this opens up a whole new set of possibilities like printing out the dashboard for the stand up meeting, or mailing the pdf to customers and executives who want to know the current state of the iteration. I can hear you ask why they need a PDF report when they can simply log into Silver Catalyst to find out the information. At this point I’ll just say that it’s a complete mystery to me why so few project management tools provide PDF output. I’ll talk about this in more detail tomorrow.

Apart from the benefits of PDF Report itself, it also validates the plugin concept. The ability to extend Silver Catalyst with plugins is very exciting. Expect many more plugins after the v1.0 release.

This post is part of the Agile in small steps series. For a complete list of posts in this series, click here.

Is this how you currently make a release?

1. Check out code from version control
2. Execute the build script for each module
3. Execute a script to integrate all the modules
4. Execute a program to create an installer
5. Execute a script to create a CD image/Package the files into an exe/jar/war/…
6. Copy the built code to another machine/Hand over the built code to QA
7. Install/Deploy the application
8. Test the application
9. Release the application

Wouldn’t it be better if you could do something like this instead:

1. Execute release script

Impossible? Not so. The technique is to take it one step at a time.

Continue reading ‘Agile in small steps #3: The one step release build’ »

This post is part of the Agile in small steps series. For a complete list of posts in this series, click here.

Okay, this is not an agile specific practice, but I had to put it in only because I’m often baffled by the answer. At first I thought this was a dumb question. Every project uses a version control system right? Right? Well, no.

This never fails to surprise me.

Continue reading ‘Agile in small steps #2: Does your project use a version control system?’ »

This post is part of the Agile in small steps series. For a complete list of posts in this series, click here.

One of the core principles of agile software development is to get rapid feedback and adjust accordingly. It goes without saying then, that the quicker you can get feedback the faster you can adapt. One of the simplest ways of reducing this time is by unit testing your own code.

Continue reading ‘Agile in small steps #1: Unit testing’ »