Robby on Rails: Tag projects

Audit Your Rails Development Team

Robby Russell — Sun, 17 Jun 2007 15:05:00 -0500

Several months ago, a few of your colleagues decided to join forces with you as you had come up with a concept for an innovative web application, shared the ideas with your friends and relatives, and began developing a business plan. After a few months of performing some initial market research, working on your pitch, and raising some initial funding, you decided to bootstrap the project and start designing and developing the product.

During your research phase, you came across several articles about this exciting new technology called, Ruby on Rails. You were impressed with many of the sites that were being developed on this new framework as well as the community that surrounded it. Your team decided that it would be a great idea to follow this trend and use Rails as the platform for your new product.

At this point, you began soliciting freelance developers and/or firms to hire for the design and implementation of your project. Eventually, you make a decision and break ground on building the product.

Let’s jump forward to the present day.

You’ve been in heavy development for quite some time. Your product has gone through a series of design changes and you’ve recently begun to allow other people to begin testing the application. You’re receiving a lot of bug reports as people use the system. Your development team quickly fixes them as they appear, but you’re noticing a trend in the development process.

The speed of implementing new features is drastically slowing down as your development team is spending most of their time fixing bugs. Along with that, they are becoming frustrated by the project because they can’t keep up with your new feature requests while trying to keep up with your growing number of bug reports. You’re becoming concerned about the stability of the product and are slightly suspicious that your developer(s) might not be as good as they suggested they were.

Did you hire a bad development team? Chances are, you may not be able to tell. You’re not a developer, so reviewing their code would almost be a waste of time. How would you know if they were doing a good or bad job? Your developers reassure you that things are going to work out in the end, but it’s going to take longer then originally planned. Along with this, your partners and investors are anxiously waiting for you to launch the product, but something feels wrong. You’re worried that launching it too soon could be the quick death of the entire project if it all comes to a screeching halt due to unforeseen bugs and problems with the application. This wasn’t how you pictured the launch of your exciting new product and you feel a lack of confidence in the entire process.

What can you do?

Before I get into that, let’s discuss some of the possible causes for this situation.

Your development team may have grossly underestimated this project.
You might have pushed too many features into the initial release of the product and your development team might not have done a good job of helping you determine what you need, not just what you want.
Your development team might not emphasize testing enough in their process.
Your development team may have begun to take a lot of short cuts in an effort to hit your launch date(s)
Perhaps you asked for quick turnarounds on new features before an investor meeting… maybe this happened on several occasions.
Your development team might not be very good with Ruby on Rails, maybe this was their first Rails project.
...and so on.

At this point, the big question is… what’s the problem?

Can you answer this question yourself? Can your development team answer it? If not, what do you do? How can you get an accurate understanding of how stable the code base of your application is?

Answer: An independent code audit and review

Why is this a good idea? Well, when you have an independent team review your code, you get the benefit of having a fresh perspective.. and often times, an independent team can be much more critical and provide an honest assessment in a very short period of time. This is especially true if they have a lot of experience with the technology. For example, PLANET ARGON has been conducting code audits on existing projects for over two years. We’ve designed a process for checking existing code bases for mistakes that we’ve either made ourselves in the past or found in other projects that we’ve reviewed.

In fact, our process currently walks us through the following areas of your Rails application.

Security of the application
Privacy of users’ personal data
Adherence to the conventions of the Ruby on Rails framework
Scalability of the application
Performance of the application and data model
Testing framework and process
User interaction (when applicable)
Information Architecture
Model-View-Controller (MVC) implementation and organization

Not only does this process provide you with our analysis, but we also provide you with our advice as to where your development team should focus their attention next. If your team is lacking experience in the areas that we recommend they focus on, we’re also here to help them through this with our consulting services. We’re currently assisting several Rails development teams with their testing process, refactoring, user interaction design, optimizing their site, improving their deployment strategy, and plan the implementation of new features.

In general, most freelancers and firms could/should provide you this service, but it should not be performed by your existing development team. They have a bias towards their process and this is your chance to get a second (or third) opinion on the work that you’ve been paying them for. If you’re spending several tens/hundreds of thousands of dollars into this product, an independent review of your investment should be something to seriously consider.

There are several different scenarios that could lead you to deciding to have an independent firm perform a code audit. In fact, I’d encourage you to always get an outside perspective of your team’s work.

To learn more about the Code Audit and Review process that we provide, call us at +1 877 55 ARGON or contact us online.

Poor Communication and IT Projects

Robby Russell — Mon, 12 Mar 2007 17:25:00 -0500

InformationWeek has a short story titled, Poor Communications, Unrealistic Scheduling Lead To IT Project Failure.

“Communications failures top the list of reasons IT projects fail, according to poll results from the Computing Technology Industry Association.

About 28% of 1,000 respondents identified poor communications as the main cause of project failure, according to CompTIA, which offers project management training.”

So, while we’re all spending so much of our time focused on improving our technical skills, are we also investing our time into becoming communication superstars?

If you look back at the following posts, you’ll see some links to some excellent books on this topic.

DDD (d3) is the new conversational software development

Robby Russell — Thu, 03 Aug 2006 22:28:00 -0500

I’m not sure how I missed this recent post on Martin Fowler’s bliki last week on Customer Affinity. In this post he references when the term “agile” first came about and mentioned that, “one of Kent’s suggested names for ‘Agile’ was conversational software development – the point being that it’s a two way communication. “

Conversational Software Development.

This doesn’t sound so different than what Brian Ford and I are calling, Dialogue-Driven Development. ;-)

Fowler goes on to say, “This isn’t something like a telecoms protocol that you can define, but the back and forth discussions about how software can enhance the business are where the real value lives. Much of this conversation is of half-baked ideas, some of which grow into valuable features – often ones that aren’t things that the customer originally thought of.”

If you didn’t follow the thread of comments on my recent post on Dialogue-Driven Development, you might not know that this name came up during Martin Fowler’s keynote at RailsConf when Brian and I were sitting next to each other and Martin kept reusing the word “dialogue.” Brian and I can’t seem to agree if I said, “Dialogue-Driven Development” out loud or if he wrote it down on a piece of paper first… so we’re going to have to share the credit. What made this so fascinating at the time was that for the entire trip from Portland to Chicago on the Argon Express, Brian and I had been discussing a lot of what we’re planning to change and define with our approach to Client/Project/Development Collaboration & Management… and in the end… we left Chicago with ~~DDD~~ d3.

Thank you, Martin for being part of this process.

Like all things, this approach is open to ~~discussion~~ dialogue.

UPDATE

Brian has written an article called, It’s all about the dialogue. (digg.it)

Dialogue-Driven Development

Robby Russell — Wed, 02 Aug 2006 21:55:00 -0500

Just a few months ago, I wrote a short article called, The Art of Delivery, which outlined how we at PLANET ARGON approach iterative development and how it relates to quicker release cycles. I wanted to follow up with this and add some more thoughts to that and what we’ve been trying and learning since that point in time.

With iterative development cycles, we’re able to focus our attention on very specific and well-defined goals while we work with the client to organize the other goals that they’d like us to help develop solutions for.

An End to the Product Backlog

While everyone at PLANET ARGON has been doing some research on modern Agile-related methodologies, we’ve been throwing a lot of ideas back and forth… and often times we end up cherry-picking individual practices and throwing it into our evolving processes.

The problem that we’ve seen with most examples of using a standard Scrum Product Backlog is that it focuses too much on tasks rather than providing solutions for goals that are central to the success of the project. It also requires that someone maintain, on a regular basis, a well-defined list of tasks, which often times the client (Product Owner) dictates. We’ve seen many situations where a client has more feature requests than is necessary in order to attain the goal that was originally set. If we had a nickel for every time we heard someone say, “wouldn’t it be cool if it did this?”

I’ve personally worked on many projects that fell into this routine too early in the development cycle. Most clients that we work with are trying to provide a solution for their users and aren’t always the best Domain Expert. Taking the whole less is more approach, it’s vital that the earlier you can get your users in front of your application, the sooner you can get them to generate feedback, which aids in you making educated decisions about what to add to the project later on.

Features are Expensive

Aside from the monetary costs of adding new features and functionality, it is important to remember that as you add new code to an application you increase the maintainability and overall scope of the project. With each new feature, the requirements change, complexity increases, and as far as your users are concerned, they are now being exposed to something new, which may or may not be what they want or need. For example, I was in a sales meeting yesterday and our potential client mentioned that at a former job during the dot-com era, their web team added e-Cards to their web site and it had nothing to do with their business model. The users did however use this new feature but they later went out of business. Perhaps they should have been an e-Card business instead. Imagine if BaseCamp added a local weather feature… I might use it… but it doesn’t help me manage our projects any better.

When clients approach us with a new feature that wasn’t previously discussed, we have to ask them they Why, What, and How? What goal is this feature providing a solution for? Do we already have a solution implemented that solves this problem? Is this a new goal and how (and why) did this goal come about? What are the costs of implementing such a feature and how will it affect the current stability of the user base and application? If we put it off 3 months, would it cause the project to come to a grinding halt? What about 6 months?

It’s important to always remember that one of the biggest problems in software development is feature creep. Many projects fail due to this and as a project manager, developer, or client… please consider the consequences and benefits of each new feature. Focus on the goals and connect the dots from there.

Get the goals clearly defined and provide clear and simple solutions for them.

Just Say NO to Bloat!

Start with a Mission Statement

One of the new things that we’ve begun doing with a few new clients is assigning them with an initial task of providing us with a Mission Statement. From the Mission Statement we can ask how each goal that the client and we outline relates to it. If one of the key goals of the Mission Statement is, “to provide gorillas with easy access to basketballs”... we will have to question any goals that imply that we might also need to provide access to soccer balls, car batteries, or scissors… or that when a gorilla is getting their basketball we might want to provide them access to stock reports. We’re not trying to solve all the gorilla’s problems and it would be naive for us to think that we know what they want before we’ve had a chance to really engage in that dialogue.

Users are the Domain Experts

Very rarely do we get a chance to interact with users before we’ve begun coding a project and getting an alpha release in front of a subset of users. Brian and I just got back from a few days in Washington DC, where we worked with a new client. They have an existing GUI application that began development in the mid-90s and we’re being contracted to help build a new solution to the problem that they began to solve ten years ago. The application has suffered from a lot of feature creep as many evolving products do. As they gave us a demonstration of their existing product, we saw first hand how it was even difficult for them to remember why Feature X was in the system. “Most customers don’t use that anyways.”

So, why is it there? Of course, nobody remembers why everything is there now. As developers come and go projects get managed by various people over the course of their life, many of different opinions and features get injected into the application. It’s a common problem and it takes a lot for a company to finally admit that it’s time to throw it out the door and start fresh.

The old rules don’t apply anymore. *

One of the first things that we did in our meetings was discuss what goals their product was aiming to provide solutions for. What do they believe that their users want and need? To get this answer, we scheduled a few conference calls with real users of their existing software! I cannot describe how helpful those interviews were and we saw a lot of consistency in their goals as users of such a system. It became apparent that they were the Domain Experts and as we move forward with the project we are going to have access to interact with those users.

Rethinking the Dialogue

When thinking about delivery, we must consider the major obstacles to overcome during the course of an iteration or release cycle. More important than having well-defined deliverables is having well-defined expectations. If you’re delivering a prototype, be clear about what a prototype is and what is it not. Schedule regular meetings with your client throughout the process. Keep the client updated as much as possible. Ask questions as soon as you can… and be sure to ask them the right questions.

There is an art to it and it’s important that you keep this process lightweight and agile like you do your development process. Perhaps we need to think of development and project management under a new heading… *Dialogue-Driven Development? ~~DDD~~? ...just what we need… another acronym. ;-)

UPDATE

We’re not going to call it DDD… just d3.

The Art of Delivery, part 1

Robby Russell — Wed, 31 May 2006 00:09:00 -0500

Over the next few weeks, I am going to interact with the readers of my blog in a segment that I call… The Art of Delivery.

As a professional developer, my experience with working in development environments has been fairly unique each time. Up until PLANET ARGON, I had very little say in how we structured the very process that I was expected to follow. Granted, there is is a benefit to having leaders who have some good experience to help guide a team throughout the life span of a project, but a leader should also posses a sense of humility and stay agile in their processes. You cannot succeed in an environment where an old dog can’t learn new tricks. This sort of thinking reminds me of managers who feel that their sole responsibility is to manage people. People manage themselves, a leaders helps facilitate self-management. I’ll be the first to admit that I have much to learn in both areas. :-)

Earlier this year, the PLANET ARGON Core Team met to outline new processes. One hot topic was project communication and delivery. One of the areas that we all insist that we excel at is building better estimates and managing project delivery more efficiently. Every one on our team has their own ideas of how best to coordinate projects and we wanted to find a way to invent our own pattern… but what we realized is that we were borrowing a lot of ideas from books we’ve read as well as the lessons learned in previous environments. One of the things that we realized is that while we weren’t horrible at building estimates for a six month project… it was that we knew that the requirements of (almost) any project would change scope within six months. How could we accommodate new ideas in a project without disrupting the budget and the agreed timeline? We wanted to rethink this process and push ourselves to follow an iterative approach.

Focus on the now and then the then

Since then we have begun to define and redefine what each stage of a project looks like. How do we communicate stages of a project with our clients in a meaningful and clear way?

I’m now about to give away how we do business at PLANET ARGON.

Project(s), Release(s), Iteration(s), Task(s)

It’s not rocket science… and it shouldn’t be!

A project has many releases
A release has many iterations
An iteration has many tasks

What we do is isolate an iteration by collecting a set of goals to be accomplished that the client and we agree on as being of high value to the success of the project at this point in time. Tasks are essentially the individual steps needed to achieve those goals and we don’t go out of our way to list each one of those during an estimate process as some tasks take less time than it takes to generate an estimate for them. We include our developers in our estimate and specification process as they often have many great questions to send to the client to get further clarification. Often, much of this clarification process happens during a first iteration, which some call Iteration Zero... as no code is developed during this iteration. Prototypes, estimates, mockups, and Q&A is what iteration 1/zero consists of. This is that important design phase that people talk so much about. :-)

Let’s get back to thinking about delivery… and we’ll make the assumption that you’ve already worked out your estimates and are now ready to work on your (next) iteration.

Open Question: As developers, project managers, and curious readers… how do you proceed?

...to be continued

The Daily Stand Up, part 2

Robby Russell — Mon, 29 May 2006 11:11:00 -0500

In a previous post, I outlined how the PLANET ARGON team handles their communication of day-to-day work with the daily stand-up. Several people posted comments about similar processes and some suggestions were made to keep them from getting too stagnant. I wanted to highlight a few of those comments.

Aslak Hellesoy suggests, “Use a token – a rubber ball or something – for each person giving status. Only the person holding the token is allowed to talk.”

Florian Weber said, “Everybody standing up makes meetings go faster and more focus…”

However, not everybody is convinced…

Doug said, “I hate meetings, why on Earth would you punish your employees on a daily basis?”

Perhaps Doug has worked in environments that encourage too many bad meetings. A client recently said, “meetings are expensive” when we agreed to not have too many meetings throughout the project. Less meetings that are well-focused are much more valuable and productive. :-)

The one that caught my attention was the comment made by Aslak Hellesoy… he goes on to say, _“When a speaker is done, throw the token to a random person instead of just handing it to the left or right. This forces everyone to stay more alert, as noone knows who’s next.”

This got me thinking about how we had made it a ritual to stand in similar positions and I would start off the meeting. The team wasn’t too keen on throwing a ball around the room as we often hold coffee in our hand… so I came up with the following solution…. which reunites us with our little friends, the index cards!

Basically, all I did was take a stack of index cards and write a number on each one. Then at 9:15am PST, we all walk into the meeting room and take one. Whoever got #1 goes first and we work our way up from there. We’ve done this three times so far and most of the team seems cool with it. I’ll keep you posted as we solidify our approach to The Daily Stand-up.

...and of course… this comment also reaffirmed our decisions to do daily stand-ups…

Kevin Rutherford said, “Cool. And by “inventing” the idea yourselves, I guess you have much greater buy-in too?”

The Daily Stand Up

Robby Russell — Mon, 22 May 2006 23:57:00 -0500

I’ll admit it. I’ve never read a book that outlines that SCRUM process in detail but do have a copy of The Art of Project Management by Scott Berkun. In chapter ten, Berkun points out the purpose of having meetings as well as the annoyances that surround them. Over the past six months, we have toyed around with a few different approaches to holding meetings. There was a short period of time where we really weren’t sure what the best way to get company-wide information to everyone without boring them to death once a month or week.

A few months ago we tried something totally crazy… daily meetings! It caught on rather well.

There is one rule though, nobody can sit down. :-)

We hold a meeting every day at the same time and do not make any exceptions. Well, I will admit that we’ve missed two or three in the past several months but overall, we’re very good at keeping to the schedule.

So, how does this process work?

Each morning, I spend about 15 minutes preparing for a 10 minute meeting… which also is how I build my list for the day. This list appears on an index card as I keep it with me throughout the whole day. I also keep the previous and next days card with me so that I can make sure that things that didn’t get done yesterday get done today or tomorrow. Some of these tasks end up on BaseCamp or just get checked off as I complete the task.

Each morning at 9:15 AM PST (now you know where we are when we aren’t working or on IRC), we meet in our conference room and stand in something that looks similar to a circle. I wait until everybody finds their way into the conference room and then say, “Good morning!” I then do go over the following things (and use my index cards to keep me on topic)...

What did I do yesterday (or Friday/weekend)?
What will I do today?

Then the person who decided to stand next to me follows and we do this around the room… I think the order this morning was:

Robby
Jeremy
Brian
Jason
David
Allison

This is a good time to also bring up any thing that might be useful for everyone to hear… such as, “we got a new development contract signed yesterday!” or “client x will be on-site at 1:30 PM.” Along with this, we’re able to ask questions about other peoples work and act as a sanity check. Why the stand up? Nobody likes to just stand around for too long… when you stand up you avoid getting too comfortable and people are more likely to stay on topic and focused.

The meetings typically last 10-15 minutes and if you’re not doing something like this with your team… how do you cope on a daily basis?