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.
As python programmers we are sometimes faced with using an API that is, well, unpythonic.
Unpythonic? Pythonic? Huh? Have you ever tried running this:
python -m this
Maybe you’re using a C library via ctypes, or you have inherited a collection of functions. Regardless, you find yourself wishing you can use the API in a more idiomatic manner.
This happened to me recently when I started working with redis-py, the defacto standard python interface to redis.
Sidebar: this post is not really about redis, but if you don’t know about it or haven’t given serious thought to using it as a datastore, run right over to http://redis.io/ and read up on this amazing in-memory, key-value store. If you’re familiar with memcached, then you’ll have a general idea of redis, but redis goes well beyond simple key-value pair storage. It also has functionality for storing lists, sets, sorted sets and hashes. Redis is often described as an in-memory data structure server.
In using redis-py, you acquire an instance to a monolithic object that manages a connection pool as well as the underlying redis protocol, offering a method for every redis command. While being feature complete, the object is a bit unwieldy, imho. Typical usage might look like this:
>>> import redis
>>> conn = redis.StrictRedis()
>>> conn.set('foo', 'bar')
>>> print conn.get('foo')
>>> for c in 'this is a test':
... conn.sadd('myset', c)
>>> print conn.smembers('myset')
set(['a', ' ', 'e', 'i', 'h', 's', 't'])
Every command for every data structure is attached to an instance of
StrictRedis. If you look at the redis command set you will see there are some commands that apply to all data structures, while others apply to one data structure or another. For example, commands like
ttl can be used against any key in the datastore, while commands
incr, can only be applied to strings, and
hset can only be applied to hashes.
A picture begins to form for the potential for an abstract base class,
Key, with concrete subclasses
We will explore how to create a more pythonic interface for redis, building off the powerful redis-py implementation, using minimal code by using advanced python attribute access and delegation.