• Read more about How to Find and Kill a Rogue Server Process

What do you do when you cannot start a new server session because the address is already in use? It happens to the best of us, such as this morning when I exited my terminal without first quitting the rails server. I found myself faced with this error in my new terminal when trying to spool up a localhost:

 ? ./script/server => Booting WEBrick => Rails 2.3.11 application starting on http://0.0.0.0:3000 => Call with -d to detach => Ctrl-C to shutdown server [2011-12-22 11:41:15] INFO  WEBrick 1.3.1 [2011-12-22 11:41:15] INFO  ruby 1.8.7 (2011-02-18) [i686-darwin10.7.0] [2011-12-22 11:41:15] WARN  TCPServer Error: Address already in use - bind(2) Exiting

I Googled around for some information, but ultimately Paul was able to troubleshoot my issue over corp chat. Here’s the solution that worked:

Enter this into the terminal:

 lsof -i TCP:3000

It will yield a result that might look something like this:

 renaebair@siren ~/workspace/intridea/newsite (master)  ? lsof -i TCP:3000 COMMAND  PID   USER       FD     TYPE     DEVICE     SIZE/OFF    NODE   NAME ruby   68780   renaebair   6u    IPv4     0x10898278     0t0      TCP     *:hbci (LISTEN)

Grab the process number (a.k.a. PID) (in this case it was 68780) and then type “kill #{that_pid}”:

 kill 68780

Then try restarting your server and all should be well!

Paul here with a few quick words about what’s going on in this case:
When Renae closed her terminal session with the rails server still running, the server process became orphaned. It was still active and serving pages on localhost:3000, but without a controlling terminal window, Renae was not sure how to stop it. Also, because it was bound to port 3000 it prevented a new rails server from starting on the same port. The lsof command is used to list open files, in this case the pseudo-file for tcp port 3000. (It can also be used to figure out what processes are logging to a file lsof log/development.log. This is sometimes useful when a plugin is writing to the rails log instead of its own log file.)

Once we have the PID for Renae’s orphaned process, we can send a signal to it, telling it to close itself. The kill command is the mechanism for sending that signal. To be polite, we first send a TERM signal, which roughly means, “Would you please finish up what you’re doing and close, dearie?” If that doesn’t work in a reasonable time, we can send a KILL signal (side note: I find it unfortunate that the signal and the command share a name, but that precedent is older than I am) kill -9 some_pid which translates to “KILL IT WITH FIRE”. As in real life, being less polite may result in needing to handle some cleanup yourself.

There is a slightly easier option. If we suspect that port 3000 is bound to a rogue rails process, you can use the killall command as a more “shotgun” approach. But what fun is that?

• Read more about Redesigning Agile: Part I - Challenges

One of the best comments I've heard about Agile development is that "adopting Agile is itself an agile process". It sums up very nicely the fact that each team and each project will have their own needs when it comes to finding a process that works for everyone, including the stakeholders. It also means that no matter how much you like a specific methodology, it's virtually impossible to implement that process on your team following its strict definition.

As a Scrum Master I've always been partial to Scrum, but after spending six months trying to make it work on one of our large client projects, I reevaluated and started from the ground up to design a whole new Agile process. We'll be introducing our new process in a future blog post, but for now I wanted to talk about some of the challenges we faced implementing Scrum.

There was nothing specific that was wrong with Scrum for our project. We just ran into enough minor hiccups that we started to lose some of the benefits that we should have been able to reap by using it. Before starting, I needed to figure out exactly what wasn't working (and also what was working well) with Scrum so that those issues could be addressed by our new process.

Here are some highlights of our challenges:

• Missing or ambiguous roles

  Scrum works best when a strong Product Owner and a strong Scrum Master maintain a bit of tension between them. The PO needs to demand more and the SM needs to keep things reasonable. The result is an aggressive schedule with a great deal getting done, but development kept to a sustainable pace.

  This can break down if your Scrum Master needs to do a lot of the product planning and prioritization (or isn't involved enough in the planning process). Likewise you can also run into significant problems if you have trouble finding someone who is both empowered and knowledgable enough to be a strong Product Owner.

  Another potential issue is that as painful as it may be, priorities sometimes need to be set by a committee. If the client can’t abide by a single person who selects the features for the upcoming iteration, the process needs to be flexible enough to support that. This also means that if the person who is most responsible for setting priorities is unavailable, then one or more surrogates can easily step in.

• Self-organization doesn't work for every project

  Even when you have competent and self-motivated developers, not all teams work well when attempting to self-organize. For our team, there were a few factors that made it a challenge.

  First, we were regularly adding and removing people. As other projects spun up or down, we would have fairly regular shifts in team composition. While we always had the same number of developers, we frequently had new developers coming on who were new to the system. Since our product is highly complex, they simply could not figure out which of the backlog items from the current iteration were good ones to try to work on.

  Second, with a team spread out across the world, real-time collaboration is hard. In our case we have developers across the US and China and were working with client contacts in every US time zone as well as Spain and South Africa, making it impractical to rely on instant availability. The consequence is that your team needs to be more autonomous and focused on working independently. In my experience, self-organization works best when the whole development team is collocated and able to work with one another face-to-face.

  Last, the client will sometimes need more detailed insight into who is working on what. In traditional scrum, having a backlog story hanging out and unassigned at the beginning of a iteration can make some clients uneasy.

  To get around these issues, we found that the project manager for the development team needs to assign tasking to provide focus and avoid issues with non-real-time collaboration. This needs to be done in such a way that the clients are aware of the assignments, but the developers are still empowered with technical and design decisions without needing approval.

• Rigidly timed iterations can break velocity

  There are a number of situations where having a fixed-time iteration doesn’t work. In the web development world, you will often have short (e.g. 1 week) iterations. Many features easily fit into one iteration, but often a large feature needs to be spread across multiple iterations and simply cannot be broken down into concrete backlog items that can be deemed complete during a single iteration. Also, changes in client schedules, shifting personnel, and unexpected things like conferences, holidays, etc. can make iteration timing problematic.

  Scrum requires a stable team that has a consistent velocity. That velocity is used to determine how much to tackle in the next iteration. The problem is that a team’s velocity is based on the past performance of that team (i.e. how much they got done during the last few iterations). When you have a team that either changes frequently because of personnel or unstable iteration times and shifting customer requirements, then the velocity can become unstable.

  When these factors affect velocity, your most important planning metric becomes meaningless.

• Better transparency into release schedules

  With web development, you often end up in a cycle where major new features come out each iteration and marketing of those features can get lost in the noise. We need a way to say “the next major version of our site is online and it includes features foo, bar, and baz”. The client needs an opportunity to brag about progress and plan ahead for potential downtime.

• Incorporate a mechanism for QA and bug fix cycles

  There needs to be a clean way for the QA team to be fully integrated into the iteration cycle. The acceptance criteria and the planning of regression tests need to be a core part of the process while not holding up the development team. If you have separate QA and development teams then your developers can end up sitting around waiting for QA at the end of a sprint in Scrum.

  At the same time, there needs to be a real dedication to continuous code improvement and bug fixing that isn't dependent on the Product Owner deciding to prioritize those fixes.

While accommodating all of these changes, we still needed to harvest some of the benefits of Scrum and other Agile processes.

Even though we were looking for a process that would allow our clients more insight into who was working on what, we still wanted our developers to be able to focus on the task at hand and not be concerned with shifting priorities or popup crises. The client needs to remain hands-off and the process needs to be set up to make that comfortable for both the client and the development team.

Obviously one of the biggest advantages with Agile development is that you are able to respond to changing requirements (the idea of dropping “ready, aim, fire” in favor of “ready, fire, aim, aim, aim, aim, …”). The new process needs to support that as well or better than the process it is replacing.

These are some of the most important issues that we needed to incorporate into our new process. In the next post in this series, we'll actually describe our new process and how it works. After that, we'll include some tips for implementing it on your project and some of the challenges that might come up.

• Read more about The Importance of Aesthetics

The other day when Zoho People was announced I came to the realization that even though I had heard about Zoho in 20 different blog posts over the last year or so, I had never taken a moment to go check out what they were all about. With a full online office suite, it’s definitely something I’m interested in and could use. So why didn’t I take 5 minutes to explore further?

Their Logo. It had been attached to all of the posts about them, and when I see it I just instantly lose interest in the company and their products. This is not the logo of a company that wants to be taken seriously for a productivity suite, it’s the logo of some company that sells teddy bears online that you can customize…or something. It is such a stark disconnect from the target demographic that I really just can’t understand the thought process that went into it.

Now I may be shallow in writing off this company solely because I didn’t like the look of their logo (though I would argue that’s a perfectly reasonable thing to do), but the point is that it doesn’t matter at all what features, awesome back-end programming, and next-generation online collaboration Zoho offers. I never found out more about them because the image I was presented was not one that appealed to me.

The design of a company’s logo, its products, its website, everything, are not throwaway concerns. In a split-second, a person might look at your corporate website and decide “This company doesn’t look professional enough.” There is a critical period in the very first moments a potential customer sees your product that may well inform the rest of your relationship with that customer. Without an appealing aesthetic front, you will never make it to the meat of your pitch, because they have already written it off mentally.

This, I feel, was the largest gap between my college Computer Science education and the real world. I’ve always been a designer as well as a developer, but when there was absolutely no emphasis placed on the user experience or the aesthetics of the software that we were building for classes, I got frustrated. Not everyone has an eye for design, and that’s not a problem. But if a product is to be taken seriously, someone along the line has to take it and make it look good, because behind-the-scenes magic will always be just that: behind the scenes.