Monthly Archives: April 2009

8 signs of a great development environment

Posted on by
  1. At least one person playing the air-guitar or drums at any given time
  2. Free coffee and soda
  3. Little bit chatter from pairing, conversation, and collaboration
  4. Lots of headphones to drown out the chatter
  5. At least one book on everyone’s desk
  6. The majority of the desks are filled, aka everyone isn’t always in meetings
  7. You can play bingo with the words test, unit, mock, loosely coupled, automate, build, pairing, code review, and powershell (Okay, maybe I threw that last one in there)
  8. Employees ask to come in and work 12 hours on a Saturday for a Hackathon

Next Hackathon, May 9th. High hopes for lots of great things to come out of it.

Scrum Tip: Tools change with team dynamics

Posted on by

My teams have been practicing Scrum for nearly a year, and it has been an eye opening experience. I have learned a lot, as has everyone at Mailtrust. I hope to post a few Scrum tips every now and again to help others learn from our mistakes and experiences.

The first tip is don’t pick one tool for all your teams. Picking one shiny tool seems like the route to go when you first start Scrumming (that feels like a dirty word), but it isn’t. The Agile manifesto states something very important about how teams should be managed, and it says it for a reason.

Individuals and interactions over processes and tools

Team dynamics should influence the tools used during the Scrum process, not management or the company or anything else.

We have been through a few major iterations of tools, and here is what we have seen.

First Attempt – Excel

Excel was the obvious first choice we made for managing Scrum projects. The problem is, it is very hard to collaborate. This was a huge draw back that everyone hated. We quickly looked for other options.

Second Attempt – Google Docs

Google Docs took the power of Excel and made it collaborative. Pretty awesome. Many teams loved this approach. It was easy to have burndown charts, calculate availablility, etc.

The teams it didn’t work for were the larger teams. These larger teams needed much more flexibility than Google Docs had to offer. The fact is, Google Docs is pretty cumbersome when you have to make a lot of changes. Large teams are large for a reason. They have a lot going on. Lots of bugs come in. Lots of tasks are getting worked on. Lots of impediments occur. Lots of notes need to be taken on tasks. Lots of tweaks to the process need to happen each sprint. These teams needed something better.

My smaller teams took the exit ramp at Google Docs. They are still using it and it is working great. They don’t have as many changes or bugs coming in, so Google Docs isn’t as cumbersome. These teams are usually backend teams where priorities are much less volatile.

Third Attempt – The Board

The larger teams needed ultimate flexibility. Managing dependencies, priorities, and status of tasks and stories needed to be easier. So we went backwards in time, to the days before computers. To pencil and paper.

It has worked great for larger teams. At first, I didn’t think it would but pencil, paper, and a wall are so free-form, the team can develop the process that works best for them. That’s exactly why the larger teams are loving the wall. Here are some different things teams are doing with the board.

  • Different color post it to signify things like dependencies and test failures
  • Organize bugs at the top of the board. This is great for managers like me to see whether a team is getting killed with bug reports.
  • Limit the number of stories available to be worked on. This helps prevent teams from getting 90% of each story done instead of 90% of the total stories.
  • Limit the number of tasks in each status, like working, review, and testing. This forces team members to move tasks through the process and not leave them hanging around

board

Next Attempt – ?

If you haven’t noticed, the teams have been iterating, not just on the product, but on the process over the past year. This is at the heart of making Scrum successful for you teams. Each team will adapt and change the process to their needs, which is fine with me. As long as they continue to operate effectively, they are free to use whatever tool they need.

Backup Integrity Checks in the Cloud

Posted on by

Moving into the cloud is a big paradigm shift. Its hard to imagine what such a big change might look like, so start small. Don’t try to offload your whole system at once. Offload the small stuff that doesn’t fit anywhere else.

One interesting use case for using the cloud is backup integrity checks for databases. Here is the scenario. You are doing backups regularly of your databases. You need to restore them every once and a while and verify they aren’t corrupt. There are a few options:

  • Run this on your production server – Asking for trouble
  • Run this on a dedicated server for integrity checks – $$$ Expensive
  • Run this on a shared machine – Sharing is for adolescents, your developers should share as little as possible

But there is one more option, infrastructure in the cloud. One of my teams recently started using cloud servers to perform the actual verification checks. So you continue to do the backups as normal. But now, your integrity checks spin up a new server in a few minutes, upload the data and verification code, and run the tests. Once your done, you spin down the server and your done. (Cloud servers doesn’t have an API yet, so we just leave a cheap instance running currently, but once the API is released it will be fully automated)

cloud-server-screen

This is very useful for a few reasons. You don’t mess with your production environment. You only need a small amount of computing power to accomplish this, so you only pay for a small amount of computing power. You don’t share servers, so one team can’t hurt other teams.

Once you understand the new paradigm, super simple solutions to problems start appearing everywhere. Don’t try to rewrite everything at once, just start making small iterative changes that make sense.

Why I like WPF, yet dislike Web Forms

Posted on by

I have been playing with WPF over the past few weeks, and I kind of like it. What’s odd is I hate Web Forms, which has very similar concepts to WPF. Concepts like controls, data binding, data templates, etc…

Why do I think WPF works while Web Forms don’t?

The first step is really understanding what I dislike in Web Forms. Two reasons, ViewState and controls.

ViewState

I hate the ViewState. It is a very complex mechanism of changing a stateless medium, HTTP, into a stateful one. While it accomplishes that task, I don’t believe the trade-offs are worth it. Developers must understand how HTTP works, and how the ViewState works. It is not an abstraction that allows ignorance because it leaks all the intricacies of HTTP as well as adding a ton of complexity on top of it.

I think understanding HTTP is stateless and coding your application to work in that medium is much easier than coding your application to be stateful and fixing it to work in a stateless medium.

Controls

Imagine you had a markup language that controls how something is displayed. It is ubiquitous and highly standardized. Now create an abstraction that wraps it, hides the simplicity, and adds ViewState, which I obviously don’t like. That is what controls in Web Forms are.

Let me interject that I don’t hate controls like I hate the ViewState. I actually like some of the principles behind them. The ability to easily reuse HTML is great. The ability to data-bind to objects is awesome.

What I don’t like is the fact that I believe it is an unnecessary abstraction. At the end of the day, all a browser cares about is HTML. And I love HTML and am good at HTML. Why take that away from me? Not to mention things like repeaters are just foreach loops.

Why is WPF different?

Two reasons that you can probably guess.

Desktop apps are stateful. There is no ViewState. There is just memory. And I understand memory.

Controls are the real thing, not an abstraction around the real thing (Yes I understand they are actually an abstraction around something, but it is a good abstraction. One that doesn’t leak like crazy. I can ignore how it works under the hood).

Now WPF isn’t perfect. Unit testing out of the bag isn’t easy, but it is possible. Just like using model-view-presenter is possible in web forms.

Review: Harmony One Remote

Posted on by

The Harmony One is easily the best buy of the past 6 months for me (even though someone bought it for me). For anyone with more than 1 home theater device, get this remote. Since I bought this remote, I have lost all my other remotes, and it is a good thing.

It is a universal remote that focuses more on user actions that devices and inputs. For example, you can create a Watch TV action that turns on the TV, Receiver, and cable box together, and sets everything to the right input. Very simple and easy to use.

But enough of my gushing over the device…let’s get objective/subjective.

Why is it sweet?

On the instructions, it warns you that setup will probably take about 30 minutes of the remote. It was exactly 30 minutes for me to get everything working. After this configuration, I haven’t had to update anything in 3 months.

I like it because it just works. I press Watch TV or Watch DVD and all my devices get turned on and set to the right inputs. But, what’s even better is the Help button, which tries to fix any problems, in case you accidentally pointed the remote at your toaster instead of your TV. I probably use the help button once a week, and every other time everything works perfectly anyways.

And don’t let me forget, it has a beautiful design. From the body to the touch screen, its sweet (for some reason I felt dirty saying that).

But these are all tangent to the real reason this remote is amazing. My girlfriend doesn’t call me asking how to watch a DVD on the XBOX anymore. You don’t have to play the role of tech support for your home theater.

Any bad thoughts?

None. My only word of warning would be this remote is for making things work, not adjusting the rotary girder of your Killer Audio Receiver 3000. Very detailed settings like independent speaker volumes and such may be hidden in menus or non-existent.

logitech-harmony-one