Why design is fundamental to web application development for us:

1. Design is important. Perfect functionality without good design is, at best, ugly— at worst, entirely unusable. If we pride ourselves on quality functionality, let’s dress in up in suit and tie. The impact on clients and users will be multiplied.

2. “Pixel perfect” implementation is a lackluster way to approach web design. First of all, the reality of browsers will never allow that to happen in every view without major cost bloat to product owners. Second of all, the concept exists almost solely because designers don’t trust you. Designers do a lot of legitimate work making a lot of decisions about how things should sit on the page. When those decisions aren’t translated to the web page, they feel slighted and frustrated. So they hang the idea of pixel perfection over our heads. Instead, let’s respect the designers position in the process. We can do this by learning about the craft of UX, Typography and Grid-based Design— as well as Color Theory. We can also do this by communicating to the product owner that we know that their design is important and that we intend to be faithful to it. Rather than blindly committing to pixel perfection, let’s commit to understanding the style guide, layout, and type decisions and budgeting meaningful time and effort to implement the site correctly.

3. By understanding design fundamentals and CSS techniques, doing our jobs well will become easier. Pixel perfection can be a cop-out for us too. We think that we will just match the design perfectly without thought. But how many of us are surprised at our inaccuracies when we overlay our work with that of the designer? By understanding design basics, we can mentally categorize design decisions that our clients have made and more accurately predict such things as fonts, font size, padding, margins, widths, etc.

@williampriceiii

In explaining the theory, Beck uses the analogy of washing, drying and folding clothes. You might have a high capacity washer and have the whole family help with folding, but if your dryer is a compact low energy model like you’d find in a cramped Dutch apartment, you’re not going to have a lot of system throughput.

Broken down, a typical sprint could be:

Planning (Planning with client, tasking, estimating hours)
Development (Actual coding, feedback from client, AC negotiations)
Completion (Demo, shipping the new feature set)

In some cases we have a constraint with planning. We sometimes don’t gather all of the requirements when talking with the client, or we spend an inordinate amount of time tasking or our task estimates end up being wildly off. While we might excel in the Development and Completion stages, we lose out on increased efficiency with the bottleneck that is Planning.

In other cases we might quickly get through Planning, but when it comes time for development and shipping the software we struggle with clients who are allowed to operate outside of our process or throw negotiations out the window in an effort to “just get things done”.

So, how can we identify the constraint(s)? This requires the disciplined tracking of time spent as a result of internal and external decisions, along with the willingness to introspect on the effect of those decisions with regard to the throughput of the “system”. In other words, track your time effectively and don’t lie to yourself.

Bob: “We sure spent a lot of time tasking this week, we didn’t even get started until Tuesday afternoon.”
Tom: “Well, we thought it was a good idea to review the code while tasking and have the entire team review the tasks afterwords.”

—

Jim: “So I guess we’re changing things up today, the client has got a demo tomorrow so we have to finish this tonight.”
Eric: “It’d be nice if we could really nail down a sprints’ worth of work for these guys, we never seem to get much momentum.”
1 Beck, K (2005). Extreme Programming Explained: Embrace Change (Second Edition). Upper Saddle River, NJ. Pearson Education, Inc.

Fortunately, the City of Chandler was able to track the staff at Integrum down and award them the 2010 Small Business of the Year award at a banquet held last Wednesday.

The 23rd Annual Awards Dinner took place at the Crowne Plaza San Marcos Resort in downtown Chandler. The event celebrates individual and business excellent in the community. Integrum was chosen based on the company’s contributions to the growth of the local economy, high quality service and innovations in the field of software development. Additionally, Integrum was recognized for the company’s community involvement through its nonprofit, Gangplank.

Jade Meskill and Derek Neighbors were on hand to accept the award.

We are in process of creating some patches to allow notifications to be sent using Redis instead of by rake task.

Serious deprecations will occur as part of this transistion, but there is still a lot of backwards compatibility support that will be available for a short time.  Rails 3.0 adds Active Model ORM abstraction, Abstract Controller generic controller abstraction as well as a consistent Plugin API giving developers full access to all the Rails internals that make Action Mailer, Action Controller, Action View, Active Record and Active Resource work.

There is a great guide on over at Rails Guide that talks about converting an existing Rails application to 3.0.  We have flipped the switch and are now doing all new development officially in Rails 3.  Furthermore, we have started our strategy to convert existing applications to Rails 3.  We would love to hear about your experiences with upgrading and your current strategies for new development.