How you develop enables what you develop.

Management gurus have been preaching for decades that the best, easiest, fastest, cheapest (pick any four) way to improve what you do as an organization is to improve how you do it. And, particularly in the craft of software development, those lessons have been gradually taking root and helping teams deliver better software at least since the days of Brooks' The Mythical Man-Month, first published in 1975. We've spent the last 35 years reaffirming the truth of Brooks' Law, and steadily developing more effective processes for developing software.

As projects have become more complex, requiring more information and better access to it to be successful, development processes have often struggled to keep pace. "But we've always done it this way" is becoming a reliable signal of imminent project failure, not merely a humorous anecdote. Because projects take time to develop, and because business needs change over time, the demands on any project are quite likely to change over the time that it takes to develop; a process that depends on knowing "all the answers" before coding even starts is unlikely to succeed the first time – or the tenth. Certainly, teams have discovered that it is impossible to delight their customer (internal or external) without that customer (or his surrogate) being intimately involved throughout the process.

Without that involvement – as well as several other factors in the development process – industry experience clearly shows development to be actively counterproductive. Numerous people have written extensively on various other conditions affecting success: for instance, Joel Spolsky's "Joel Test" discusses conditions that dramatically improve the odds of a successful project, and this Computerworld story from 2004 talks about the doom, death and successful rebirth of a project that learned these lessons the hard way. Your project doesn't have to.

What we bring to the discussion.

Our Principal Technical Consultant, Jeff Dickey, has over thirty years of experience in the software and Web development industries. He is a veteran of projects in organizations ranging from Microsoft and IBM to the most barely started startups, on four continents and in cyberspace. He has gone from writing great code to giving strategy presentations to senior executives to helping teams snatch project success from the closing jaws of apparently inevitable doom – often all within an uncomfortably small timeframe.

He's learned a lot about what (usually) works well and what (almost always) fails spectacularly, and enjoys sharing the benefit of his experience with technical and non-technical stakeholders alike. He has been involved with numerous internal, commercial and non-commercial projects, both proprietary and open source.

He has also previously been a Certified Quality Engineer, and understands all too well the differences between the craft of software development and an engineering discipline. A prolific writer, blogger and commentator, he is also highly experienced in helping teams fine-tune their communication between stakeholders, whether across the hall or across the planet.

In addition, we have associates in various disciplines whom we have worked with previously and whose work we serve as your single point of contact for. As a cliché reminds us, "one reason open source software has had a tough time in the enterprise is that it too often doesn't give the customer 'one neck to choke' if things go wrong." We mitigate that issue, and our "neck" is in quite unconstricted condition. So far.

How can we help?