Skip to main content

Posts

Showing posts from October, 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 configura…

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 fea…
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 "softwa…

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. T…