Skip to main content

Distributed Development / Divorced Software Development

In an attempt to dispel the level of optimism in distributed teams: I'd like to negatively state that divorcing your team like this is the worst way to achieve team efficiency and sustain a high level of quality in your products. None the less, it still happens project to project. I've bounced back and forth between teams where we've stuck in pods (all in one common area) and some where I'm dealing with teammates in a different continent. Sadly, most of the projects that have somehow dwindled down the path of hiring cross continent resources have been the most stressful.

It's not the people that cause problems. As a matter of fact, the team is usually composed of wonderfully talented and smart people -- It's the ineffective communication channels that get incorporated into the delivery process that ultimately divorces team/client expectations.

My primary concern about distributed teams is that upper management fails to see the overall picture of software delivery. Developing software that will indubitably be shipped out to users is not like building toys and shipping it out to kids. Software isn't' built in factories--it's an evolutionary product that empowers your users. Furthermore, there is this imagery that is seeded into the minds of upper management of a programmer building doorknobs (components) that go into doors (web application) and get put into houses (infrastructure/platform). Negatively, we face these issues because of upper management's idea of "how software is shipped to real world users" is hazed and often imagined as a crew of factory workers in a line creating door knobs. On the whole, this stigma isn't exactly targeted to just programmers but to anyone on the production team, such as, designers and quality assurance.

In order to build great software for your users, your team should have a realistic picture and shared vision of how their loyal customers are going to use it. Distributed development--I mean, divorced development not only blinds some of your team members but painfully discourages any sort of effective participation to improve the product. If you hired a programmer from China when your team is in New York, suddenly, he thinks of a great idea of how to make a particular feature more convenient to the user, how is he supposed to communicate this to the team? He has several ineffective ways:

1) Email (which everyone can easily ignore)
2) Calling into scrums/meetings (which is completely useless if people don't document it)
3) Phone call to the lead developer (which everyone can easily ignore as well)

I'm not bashing the fact that the developer is from another part of the world--I am bashing companies with an upper management that enforces such ridiculous team compositions that essentially paralyzes your ability to build great products. I feel sorry for teammates that are far from the core team (design, development, and quality assurance) when they want to participate in the improvement of their delivery but can't due to their proximity and the limiting factors that snare their ability to communicate effectively. Ultimately, team compositions using distributed development practices encourages and amplifies corporate learning disabilities, such as:

1) I Am My Position
2) The Enemy Is Out There

Business has always been about relationships and communication. Indeed, your company can save millions of dollars in development by outsourcing but if you do decide to use this software delivery strategy, then keep constantly inspecting the level of quality in your product line. Upper management will always have a level of blindness to the quality of their product and will always see how much upfront costs they can save if they indoctrinate distributed development processes. If your management team doesn't know how to use the product that you're trying to build, they will never really have the sense of how great the product is for their users as a human being.



Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, and Cox Communications. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.
Post a Comment

Popular posts from this blog

TextMate Tutorial: How to add a Strikethrough keybind to your Markdown bundle

Markdown is awesome for quickly generating Readme's on Github. After looking at other projects using the strike tag, I've decided to create a custom keybind for it in my TextMate Markdown bundle. Here's how:

1) Click the + sign on the bottom left and click New Command.
2) Paste this into the editbox and make sure you name your command "Strikethrough".

For the input field, select WORD in the drop down.
For the output field, select "insert as snippet".
As for the keybind, you can totally map it to whatever you're comfortable with but I chose Command-D as it is the same thing in Microsoft Word.

Cheers,
Jaime

Using Git Hooks: Prepare Commit Message to automatically prepend branch names on commit messages

When you're practicing branch by feature with distributed version control, typically you'll get assigned a ticket or issue and that ends up being your feature branch. Instead of always typing in the branch name in every commit, you can edit your Git hooks (specifically prepare-commit-msg).

Assuming that this is a brand new git repository:

mv .git/hooks/prepare-commit-msg.sample .git/hooks/prepare-commit-msg
vi .git/hooks/prepare-commit-msg

Edit the file by commenting out what was originally in the file and then add this:



Now, whenever you make a commit, it should show up like this in the log:



Since GitHub and Bitbucket both support Emojis inside commit messages, you can do something cute like this



Want more emojis? check out the Emoji Mardown Cheatsheet!

NodeJS Hack Session: MMO Pokemon with NodeJS/WebSockets

The primary focus of this proof of concept is to determine how easy it is to build real-time web applications for all iPad, iPhone, droids, Safari, Chrome users on top of NodeJS (non-blocking event driven server side Javascript platform). The proof of concept was built within 6-8 hours including the following:

Uses Express framework for server side Javascript development (inspired by Rails / Sinatra / Django)Uses EJS for templating language (much like Django templates and symfony) -- allows partials and passing parameters into partials like symfony PHPReal-time chat using WebSocketsArena Queueing System for real-time competitive matchplay using WebSocketsHTML5 AudioCSS3 transitions for all hand cards, tappable cards, transparent panels, rounded corners, drop shadowsFallbacks for Firefox, IEFirefox/IE will fall back to Flash socketIE will fall back to XHR long poll if the user doesn't have Flash installedNoSQL CouchDB for fetching users and soon cards, achievements, friend associat…