Not the only one who thinks constraints are required

An older post by Obie Fernandez speaks to the constraint thread I find running through many disciplines. I've now spent almost 8 months trying to bring agile to a traditional design agency and we've had some amazing success and terrible failures. I went back and read through all my blog entries I created at the start of this journey and I never explained what my thoughts and perspectives are on constraints.

When solving a problem in a problem space with almost unlimited possible solutions, such as architecture, graphic design, or software engineering, the use of an over-arching design principal is absolutely required for success. Really good solutions often rendre the underlying principal invisible. The visitor to the solution site (words, websites, code) may not be able to immediately artiuclate what the principal or principals were, but they can immediately tell a well-ordered paradigm. The Kool-Aid crowd of the RoR scene has embraced a very strong design principal in Rails. What are some other examples of this principal at work?

Graphic designers have to tell a story when creating their portfolio. There has to be an arc to the story they tell. It's often useful to think, ok, this portofolio is going to evolve along the color wheel. The start of the book will be red, then green, then blue. I will tell a story using color. The solution is transparent, yet the visitor feels a smooth sense of flow to the book without knowing why. It doesn't matter whether they identify the arc or not, its existence and the book's adhearance to the rule makes it coherant.

Usability is the study of creating a coherant language in your software site. The use of personas and stories with a "so that" clause are great examples of creating a well-defined guiding principal that leads to a condition of self-contained coherance. It is very much a semoitic practice. Well designed software contains a very easy to grasp completely consistent internal logic. It may be for grandma instead of Skippy Jr., but it doesn't matter; when the logic is consistent (due of course to rigid adhearance to a simple constraint), the user is able to explore and map out the semoitic rules of the system. The surface of the software is discoverable and the way through the rabbit hole quickly becomes well-known.

OOAD uses this same technique. A well designed object has multiple constraints: closed for modification but open for extension; clearly defined responsibility; encapsulation; loose coupling; etc. When you read code that follows these prinicipals, you always already know what it does when you read it. The more you read the good code out there, you start to absorb the zeitgeist of patterns subliminally, and you start to try to factor your own code to follow these well known best practices.

Biggest take away from trying to do things right: It takes constant, ceaseless, undying devotion. The difference between doing right and doing wrong is not the amount of work or the intensity factor. It's just that you get a lot more high quality work done in less time. Desiging good OO code is really hard and coders under pressure will always revert to desperate perl hacking with arrays and hashes. Doing a stand up every dayis hard because something more "urgent" (but less important) will always come up. Tracking velocity is brutal because every day it tells you that you and/or your management (or client) is full of shit and you're not going to get it all done on time (probably because most of what you're doing is not valuable anyway and you haven't thrown out the junk with enough constraints - you were driving to get the dollar rather than being driven by a well defined ROI MMF business reality).

Biggest Failures

• No code review, whether by pairing or old school diffing code check-ins
• Letting ruby kool aid drinkers baffle me with bullshit when i should have seen the desperate perl hacker array and hash smash from miles away (badly named classes with no clearly defined responsibilities, more spaghetti than the tower of pisa, etc).

Biggest Successes

• Creating a true build and deploy cycle so that bad code doesn't escape into the wild
• Pivotal Tracker - it is a relentless pain to constantly drive a whole team, from business leader stakeholders down to developers to all communicate in terms of business value, but the moment you let the devs go off into implementation details or the business owners look for short cuts and quick cash, you will lose your guiding principals, all benefit and value of simple constraints and SDD goes out the window. You can't ever stray from the noble truths.

Ok this post is like a mega brain fart that has books worth of ideas in it, but i just needed to blat some of this out and get on paper so to speak. I need to really develop this idea of design constraints as a critical component for success. My unique experiences in both the design and software fields, combined with my philosophy background, gives me an interesting perspective (or the ability to endlessly romance the sound of my own keyboard clacking, you decide).