(Photo by William Warby)
I’ve worked with a lot of clients and potential clients over the past 10+ years. Sometimes, in conversation about a project, the client will roll out, oh-so-casually, one of about 10 pat statements that reveal a pernicious and erroneous belief about the process of software development. Now, most of my job involves educating clients so I take a deep breath and wade into the waters of a software-development ideation faux pas, of explaining why what the client has just said is analogous to pairing socks and sandals: Sure, it makes sense on one level, but it’s never a good idea. (Note: I’ve been chided by our development team that wool socks and Birkenstocks are certainly acceptable and that Keens and short anklets are also acceptable. I sigh. I choose to fight my battles one at a time. . .)
The objective here is to give the audience a bit of quick and dirty insight that, I hope, will help clients be . . . well, better clients. Better clients always, without exception, mean a more successful project — cheaper, faster and far, far fewer hair-tearing-out incidents. (more…)
What are you doing? Stop it. Stop hitting yourself. Stop hitting yourself!
But seriously, why are you doing that? Waterfall development, defined loosely as frontloading all specifications and performing all development with little-to-no iteration or deviation from the aforementioned specs, is the Prohibition of development methodologies. It works great on paper, but in practice you end up blind from drinking bathtub gin.
All your hopes and dreams (likely including your job and retirement fund) end up dashed on the rocks of Iguazu and you’re just left there floating in the frothy bubbling water in your nice work chinos, and your iPhone is soaked, and your ironic ‘70s polyester tie is never going to be the same.
All this could have been avoided. You could be sitting pretty right now, collecting your profit share, dry, playing Minecraft in your office where no one can see you, but you had to go with the Waterfall firm.
Let me tell you what went wrong. It really boils down to just two things. Things that seem obvious in retrospect, I’m sure, but they wreak havoc in the moment.
Most of us have probably used the term collaboration enough to have such a good idea of what it means that we don’t really have to stop to consider its implications. As the Google summary above says, the term derives from the latin word collaboratio (which also derives from the Latin terms for together (col) and and work (laborare)). Despite its similarities to the word cooperate — which also has connections to working (operari) together (co) — collaboration when it comes to software development and programming has a very distinct meaning from cooperation.
How Does Collaboration Differ From Cooperation?
While cooperating is an essential part of working with someone on a project, it does not connote a sense of ownership. This is an important distinction since ownership, the taking of responsibility for a task, is vital to working effectively when developing software. When collaborating with clients, it’s important that developers and programmers be willing to offer their clients the benefits of their expertise, particularly since it’s their expertise that clients needed when they first decided to work with an outside consultant. (more…)
In my recent post on working remotely, I’m realizing that I kind of blew past something that we’ve always felt was key to making working on a series of projects for many different projects like working for Art & Logic on A&L projects, not a series of disconnected projects.
One of the first things that the founders of A&L did was to sit down together and hash out a programming style guide. Over the years, that guide has evolved and grown, and it’s still the way that our developers write code. It’s easy to look at something like this as being a simple set of directives (“Use spaces not tabs! Opening braces go on a line by themselves!”), but it’s really much more than that.