Tuesday, October 27, 2009

The Fog of Development: Recreate Dev Workstations Often?

We're looking at using Fog to rebuild our development workstations regularly. It's a clone server that can rebuild a complete machine image across the network. I saw it in action yesterday and I was impressed - it's relatively easy to use and really fast.

So why would a developer care about sticking a new image on his workstation? When I find myself rebuilding one every week or two! It's a major time-sink to get everything working right - local database, application server, portal server, IDE, environment variables & other settings files, etc, etc, etc. I probably burn between 1-3 days each month on the mundane task of getting a base configuration down, just so I (or another team member I'm helping out) can code again.

Opinions differ about how often this should be done, but I have no doubt that it has to be done regularly. We're an agile team, so we routinely install new tools for evaluation or to spike something. We constantly tweak machine configuration to test external dependencies. I can't speak for everyone on the team, but try as I might, I can't remember every little thing that I do over the course of a week to the configuration of the machine I'm working on.

One of my teammates feels so strongly about it, he'd like to see the machines automatically rebuilt every night. I'm not so sure - I'd hate for a pair to lose a day's worth of work because each thought the other person had committed the day's changes. Of course, that would help identify people who are only committing once per day or less often...

(thanks to John Walker for the photo)

Thursday, October 22, 2009

Agile Purity: How Agile Is Agile Enough?

A Tale of Two Projects
I have been fortunate enough to work on two "green field" projects in a row. Both are/were "agile", but the way they're being managed is quite different.

The first project is/was characterized by:
  • The business folks knew at the outset what market they wanted to engage, but not exactly what they wanted the application to do. The direction was "figure it out as you go".
  • Virtually no up-front documentation.
  • Frequent changes to existing features.
  • Considerable 1x1 time between the product owners and developers.
  • We had no BA and one QA specialist was assigned shortly before production release.
  • The product, content and software development people all sat together in one big room.
  • The system is currently in production maintenance mode, with a possible version 2.0 in the future.
The second project is characterized by:
  • We are in "Sprint Zero" - doing technology and design spikes now.
  • We have detailed specifications of many required features.
  • We have several wireframes, scenarios and related documentation available up-front.
  • We have a BA assigned to the team and two QA specialists.
  • The business team is not currently sitting with the development team (though we expect / hope to change that once we start Sprint 1).
Better / Best?
The big question is, "which is better?" I think that depends entirely on which developer you ask. There are certainly advantages to having documentation and someone with a formal BA role. You don't need to have difficult conversations with the product people - that's the BA's job. One of the main disadvantages is that "you don't need to have difficult conversations with the product people" - these are the conversations that drive a better understanding of what the feature/system should do. (Determining if it does it right is another conversation entirely.)

Project 1 did get a bit wearing when we would add a feature, then remove it, then add it back in. It was the most fun I have had on a software project, though, and our velocity was enormous.

We'll have to see how things play out on Project 2. My expectation is that the documentation and specialization of roles will make some things go more smoothly. My fear is that we will find out quite late in the game that some core components of the system aren't quite what the business & customers need, and will be expensive to change.

Expect a detailed side-by-side case study in a few months, and more blog posts on related topics in the interim.

Monday, October 12, 2009

I read "Shannon Paul's Very Official Blog" this afternoon & found an interesting statement about the interaction between developers and other business folks.

What caught my attention was: "developers and engineers see it as their role to identify products or solutions — it’s your job [as a social media / marketing / product owner] to define the problem or list requirements".

I think she's saying the developers she works with see it as their job to create the product/solution based on a problem statement. I don't think this is universally true of software types - many (most) that I have worked with see it as their job to implement someone else's vision of a product. In other words, we build the software, but we don't identify the market need or product as a rule.

Many of the more entrepreneurial types do indeed handle the whole ball of wax, from ideation to development to marketing. Most of my fellow coder-nauts see themselves as "software guys" rather than entrepreneurs, though.

Perhaps a useful communication idea would be to describe how not being responsible for the product concept and marketing phases of a project will make their jobs both easier and more valuable.
"Easier" is simple enough to understand, since it means less work.

"More valuable" is more nebulous, but consider: by not getting tied to a product concept too early, you're avoiding preconceptions about what a product should be or should look like. It may not be intuitive, but in my experience having fewer preconceptions makes for better and more versatile software.

What do you think?

Thursday, October 8, 2009

Rich UI: ZK instead of Flex?

One of the other teams here at the office spiked out the use of ZK and was kind enough to give me a demo. It looks like a wonderful tool for building a rich user interface, and I'm thinking that we'll probably use it on the new application we're building. (Sprint zero starts next week.)

I had begun advocating Flex as a way to build a "real" UI. It seems like a good fit for this organization, since SEO is much less of a concern for us than it would be for someone publishing open-web applications.

Flex does have some drawbacks, though. The main problem is that we don't have expertise in Flex's XML format or ActionScript in-house. There are a lot of very good developers here, but it still takes time to learn a new tool.

The advantage of ZK is that it provides a similar user experience, but lets us write all of our code directly in Java. The downside is that it generates JavaScript from the Java code, and I don't trust generated code very much. The developers on the other project tell me that they have never had to debug the generated JavaScript, but it has only been a few weeks.

Expect to hear more on this as the team takes a deep dive into what ZK can do.

Follow-up, January 2012:
I was out of the loop on using ZK for a long time.  Now that I'm the team stuck with the codebase built on it, I can render a stronger opinion: ZK sucks.  it is nearly impossible to test.