Archive for July 2007

Basecamp to Google Spreadsheets

with one comment

After a few months with Obtiva, I’m still happy and I’m bursting at the seams to write about all of the developments happening internally. One development that I can’t keep in is our switch to Google Spreadsheets with a few of our clients.

Traditionally, we’ve used Basecamp for client facing project management. For some projects Basecamp is a wonderful tool. If your client is technically savvy then Basecamp is fabulous, but many of our clients aren’t Web 2.0 compatible. As beautiful as Basecamp’s interface is some of the finer parts are not intuitive to someone who thinks in terms of Web 1.0. The technological rift that Basecamp created was a problem because it required our clients to think and live in our webish world. For some of our clients, who are baby steps beyond e-mail, a draggable editable list is inconceivable. They were intimidated by the complexity and I began to notice the number of days since last login rise past days and weeks until the last login was about a month ago.

Meanwhile, I was using the Stylish Firefox plugin to change some of the terminology that Basecamp uses. I like to think in terms of iterations instead of milstones and the word ‘To-Do’ doesn’t give enough context for an act of work that needs to be done. Our client also had some domain specific language that was causing problems. I was hoping to ease the mental translation that happened every time I logged into Basecamp and keep the language of our projects ubiquitous

As Basecamp usage died, conversations that could be posted in the messages section of Basecamp were being sent directly via e-mail and a client shared an excel spreadsheet that contained all a punchlist of work that should be in Basecamp. Dave uploaded the spreadsheet so that we could all edit the document and suddenly we were working on the same page as our client. I think it’s important to meet clients at their technical level. Thankfully, this client displayed their level of technical expertise perfectly. Spreadsheets.

In the corporate world, the interface overhead with spreadsheets is extremely low since everyone expects the spreadsheets to define themselves in the same way through names columns, rows, and some data. Sales representatives, financial advisors, CIOs, and secretaries can all read and edit spreadsheets with ease. Since our clients are comfortable with spreadsheets they are far more willing to share them. We found out our project spreadsheets were being opened up at many desks around their office. Internally our client used the spreadsheets for project planning meetings and progress meetings. With the documents available to everyone, our work became visible throughout their entire company.

Collaboration is the place where Spreadsheets shine the most. Once the right people have access to the document all at the same time the feedback loop becomes short. Briefly, I’d like to share some of the techniques I’ve used to increase productivity and communication. Take a look at this quickly made demonstration template since we’ll be running through the columns.

Story Spreadsheet

I use On to indicate which part of a project I’m currently working on. When I start a story, I make the On cell green so that our clients quickly spot what I’m working on. Using color instead of words makes glancing much easier for them.

Description and location set the context of the story.

Rank is used by our client to indicate what should be done next. Usually the first story on the list is most important, but our clients have multiple people deciding on the order of importance. Rank gives me the ‘official’ next story while they move stories around.

Difficulty is a quick estimation of how hard the story is when technical difficulty and time to completion are considered. When a new story is on the list I give it difficult so the client can rank with that information.

Completed is filled in the moment the story is done and then I turn the story light orange once that story is deployed to production or staging.

Questions and Answers are a quick way for either party to get details straight. When a new question is entered we highlight it until the other party answers and removes the highlighting.

Iterations are inserted between stories and take up an entire row, which we color light blue to match the Google theme. Matching the color makes it easier to focus on the current iteration.

So far, these few columns with a little color thrown in have a few of our customers feeling like they know exactly what is happening and they are much happier due to that knowledge. The difference between our simple spreadsheet and Basecamp is night and day and I thought you might benefit from that knowledge


Written by syntatic

July 24, 2007 at 10:28 pm

Posted in obtiva, process

Craftsmanship as a Bridge

with 8 comments

As a third grade teacher, my wife has an instant connection with anyone she meets. She can captivate anyone for endless hours with the thousands of stories her classroom provides. People want to know what we are teaching our children, they want to know if there is still a smelly kid, and if the schools still teach children how to play The Oregon Trail, which they do. For most, talking with my wife is a nostalgic experience.

As a software developer, I generally get blank stares and questions about how to fix some problem caused by a website that was accidentally visited. Few people feel nostalgic when I explain what I do everyday in front of a computer. A year ago, conversations about my job never developed or bloomed since I couldn’t bridge the gap from what I do into their lives.

Thinking and speaking about software development in terms of craftsmanship has bridged that gap for me. It gives non-technical people a door into understanding what I do everyday. It even has me excited to talk about software development with friends and family. Treating my job as a craft or a group of skills that are artistic practices draws needed parallels to other disciplines.

Usually, I explain how blacksmithing and programming correlate. Both crafts start with very basic materials iron ore and data. Blacksmiths smelt the ore and combine it with an alloy which determines the properties of the metal. Programmers data cleanse and apply a data type which determines the properties of the data. The two disciplines are heavily dependent on strong tool sets also. Wikipedia has an interesting tidbit concerning a blacksmith’s tool set:

Over the centuries blacksmiths have taken no little pride in the fact that theirs is one of the few crafts that allows them to make the tools that are used for their craft.

The same can be said for software developers since the frameworks, scripts and commands used to build software are made up of software. However, the greatest parallels between the two crafts do not come from similar processes.

I find that the biggest eureka moments when talking with non-technical people come from the connotations of blacksmithing. Software is forged. Applications are bent, punched and hammered into shape. Different programs are welded together seamlessly. Before delivery everything must be hardened and tempered. The process is dirty and it is hot. The final product is sculpted to be both aesthetic and functional. The emotional associations the previous sentences draw upon are foreign to most when thinking about software development.

One context non-technical people discover is that blacksmiths are rare now and the craft is archaic. Shouldn’t it be more related to the assembly line or some other post industrial revolution set of practices? No, software development began in 1940 or later. Relatively speaking, the discipline is not that old. Today’s view of blacksmithing describes the current state of software development. A quote from a well known programming book applies here:

One hundred years from now, our engineering may seem as archaic as the techniques used by medieval cathedral builders seem to today’s civil engineers, while our craftsmanship will still be honored. —The Pragmatic Programmer, Dave Thomas and Andy Hunt

There is so much untapped potential that lay ahead.

Another context that I usually bring up is that of apprenticeship or more specifically craftsmanship. At the studio we follow a system of apprenticeship that is similar to craft guilds which were common when blacksmiths could be found in every town. We regularly share new practices, techniques and tools as we refine our craft together. Our job descriptions and roles mimic those of apprentice, journeyman and master also. If you’re more interested in software development as craftsmanship here are some good places to start: the next big thing, software craftsmanship.

One final side note, I’m beginning to read more about software development as an artistic medium. Few non-programmers realize how much computer languages mimic human language. Computer languages have verbs, nouns, grammar, and hundreds of other syntactic structures that parallel human languages. Programming can be a poetic experience when a few lines of code are succinct and powerful. If you’re more interested in programming as poetry join me and take a look: The Poetry of Programming, Diving for Perls – the poetry of programming, Programmers as Poets.

Written by syntatic

July 13, 2007 at 12:15 am