Mike Coyle’s Weblog

We recently announced the re-branding of our consulting practice as PyGuys.com. By marketing on a brand-by-brand basis rather than at the company level, we think that we’ll be able to improve the signal-to-noise ratio for the targeted audiences of our various products and services. For example, our Python consulting customers may not have a need for our project management software, and vice-versa.

That being said, the casual observer may wonder why we’re so gung-ho over Python when it appears that all of the cool kids are using Ruby on Rails. When we started the company in 2005, there was still plenty of room on the Rails bandwagon. Our adoption of Python was deliberate based upon the maturity of its language, libraries, and community.

Quite simply, we’re in this for the long haul, and feel that Python has the best prospects of being the dominant dynamic language in mainstream IT settings over the next 36 months. Methinks that the initial hype surrounding Rails has already started to subside, and Rails will continue as a good way of building standard web applications, especially for solo developers and small teams.

It just won’t end up being the way to build web applications.

Don’t get me wrong, the Rails folks have done a lot to validate the use of dynamic languages in mainstream settings, and the Ruby language itself has a bunch of cool and features. You will find no negativity here. But I think that Rails’ great and durable contribution to the field of software engineering is not its libraries and syntax, but rather its philosophy of “Convention over Configuration”. That philosophy transcends technology stacks, and has already found its way into a slew of web application frameworks on a number of platforms.

But when the technology rubber meets the Enterprise IT road, I believe that Python (and its community/ecosystem) is a better and more accessible choice than Ruby for most companies looking to adopt a new application development platform, current conference attendance statistics nonwithstanding.

With PyGuys.com, we’re formalizing our Python advocacy in the branding of our consulting services. In hindsight, we should have done this 3 years ago. So to paraphrase Barbara Mandrell (and there aren’t too many times in life when one gets to say that), we were Python when Python wasn’t cool. (Note: link contains audio)

Introduction

As Christian mentioned the other day, we have two new service offerings in 2008, both centered around Python consulting:

• PyCOE.com is our new offering to help organizations build core competencies in Python in a deliberate and predictable fashion in a way that is fundamentally different from the way that firms tried to adopt J2EE and .NET in the past.

  In a nutshell, we help companies create an environment where the easy thing to do is also the right thing to do for their developers, analysts, and QA personnel. We focus on culture, standards, and infrastructure as we help our customers create a Python Center of Excellence (or COE, hence the PyCOE name) in their organization. We do this by approaching Python adoption as business process re-engineering for IT, rather than programmer training.

• PyGuys.com is our new Python consulting brand. We are focusing on small-to-midsize custom development projects, and SDLC process improvement consulting. We’ve been doing Python and Project Management consulting since the company started, but we felt that now was a good time to rebrand and grow our Python consulting business.

We also reworked the Botonomy.com company website, to reflect its role as a “holding company” for our branded service offerings.

Also, just before we launched our new websites, TIOBE declared Python as the programming language of 2007. Not a bad sign, if you ask me.

We recently published our Fall 2006 Brochure. This document, available in PDF format, highlights our product and service offerings.

Here’s a short glimpse into the “Making Of” the brochure, for those of you that like that kind of thing:

As you know, our schtick is helping small teams solve large problems. So with the help of an ancient Greek, a copy of Photoshop CS2, and a few cans of Red Bull, here’s what I came up with for the first page:

The text on that page is the first half of what will probably get morphed into our “Small Team Manifesto” or “Ode to Small Teams”, or something of the like. The punchline, so to speak, is on the last page of the brochure.

The image started out as an old woodcarving of Archimedes, the famous Greek mathemetician credited with the quote:

Give me a lever long enough and a fulcrum on which to place it, and I shall move the world.

However, our mission is not to help old Greek guys solve problems by themselves. This is where Photoshop came in. The image now has a small team (i.e. Archimedes and his oft-overlooked twin brother Floyd) moving the earth with said lever.

A couple of other production notes:

• The document was produced with Apple’s Pages. I’ve owned Pages (versions 1 and 2) since it came out, but hadn’t spent any significant time using it prior to creating the brochure. It was a pleasure to work with.
• Oddly enough, Pages doesn’t ship with a landscape-oriented templates but it was really easy to set up. I built the brochure as a landscape-oriented document so that it is easier to read on a laptop screen. Kudos to Seth Godin for that tip.
• Pages plays very nicely with Adobe Illustrator, at least in my experience. This made it trivial to move our vector-based graphics into Pages.
• Even though some of the brochure content is repurposed from the Botonomy.com and ProjectPipe.com websites, some material also flowed back the other way, thanks to the creative jolt that comes with working under a different set of constraints. Specifically, many of the graphics on the latest ProjectPipe home page were initially developed for the brochure, and then repurposed for the web.

Over the years, I have developed a bit of apprehension when it comes to using WYSIWYG tools, since many visual layout tools (at least in GUI design and HTML) are a “pay me now or pay me later” proposition where you trade instant gratification for maintenance complexity downstream. That being said, it was really nice to drag stuff around in Pages, and have the layout “just work” when it came time to ship.

Python.org has a number of very interesting Success Stories of how various organizations are using Python to solve real world problems. With all of the focus on web development frameworks and such, it’s interesting to see the diverse set of problems that Python is addressing every day.

In our new case study titled Botonomy Uses Python to Create ProjectPipe.com for Web-based Project Management, I give a high-level overview of both the “why” and the “how” behind ProjectPipe.com, our hosted project management solution.

The article talks about the problem that we set out to solve, and walks through one of the more detailed “behind the scenes” overviews of ProjectPipe that we’ve published to date.

Our August newsletter is now online.  It is our first issue.   In addition to covering company news and ProjectPipe updates from the last couple of months, we also provide a sneak peek at our new hosted data syndication application, AtomAntenna, which will be in beta shortly.  Check out the newsletter for more info.

We rolled out a new site yesterday called Approach.Botonomy.Com. It is a cross between an blog and a knowledge base of project management and software development topics.

We wanted to create a way for prospective clients and partners to get a sense of Botonomy’s approach to project management and software development. But we didn’t want to just whip up some fluffy marketing prose accompanied by stock photos of a group of people we’ve never met sitting around a conference room table we’ve never sat at reviewing a project plan we never worked on.

Rather, we wanted to provide living commentary on the classical issues affecting project teams and IT organizations, as well as our $.02 on the relevant issues of the day. Hopefully, the soundness of our arguments and consistency of our philosophy will shine through the occasional longwindedness and bad spellin.

We also wanted to put together a resource that could be used to educate those coming up in the IT ranks. I’m a big fan of books like The Pragmatic Programmer, and Eric Raymond’s The Art of Unix Programming. Those are great books that provide sage advice in terms of programming and thinking about programming. But I never found anything like that that addressed some of the broader challenges facing technology consultants and IT folk in general. I am not saying that our humble website is in the same league as these classic texts, but we aspire to help those coming after us, just as those books aided scores of current IT professionals (and will continue to do so, I might add).

While Newton saw farther by standing on the shoulders of giants, we’d like to at least lend a beat-up footstool to the new kids.

From an implementation perspective, we identified a dozen concepts that are central to successful technical project delivery and risk management (focus, client relations, source control, etc.). For each of these topics, we’ll build out the following:

• An Introduction
• Our Opinions on the topic
• Short Stories that illustrate a point about the topic
• Advice, Tips, and Tricks related to the topic
• Links to current news, articles, blog posts, etc. that are related to the topic

Since it’s built atop a blog engine, it’s tricked out with RSS for the site and the individual Topics or Content Types. Every entry is tagged with a Topic, and a Content Type (Intro, Opinion, Story, etc.). This allows for a multi-dimensional view of the content as depicted below:

We have some content already published, and other stuff in various states of completion. If you’d like to see an example, here is a Story about New Technology: Your Project is Not the Science Fair

The name Botonomy comes from a combination of Bot and Autonomy. I’ll explain why. But first a quick detour through IT sourcing strategy.

I believe that innovation, rather than inexpensive labor (i.e. offshore), is the optimal path to low cost / high value technical delivery. I’m confident that hindsight will make it blatantly obvious that optimizing for team agility, rather than shooting for the lowest possible blended hourly rate, is the surest way to cost-effective quality delivery on a sustainable basis. A lack of agility makes it more difficult to adapt should a more profound understanding of the real requirements of your project come to light.

Solving the wrong problem, even at $1 per hour, is still too expensive.

For this reason, the bane of CIOs everywhere is the risk of building a well-engineered, thoroughly tested, well-documented implementation of the wrong system. It’s a situation where you spent the money (and in many cases, lots of it), and the thing that you paid for doesn’t solve your problem. Now you have two problems.

So as we surveyed the IT services marketplace, we considered two probable trends:

1. The global IT services market, like all other markets, wants to move toward equilibrium. This means that the value proposition of offshore development will likely weaken over time as the better offshore teams command higher and higher salaries.
2. Those same market forces will continue to push down the cost of computing hardware and software, as the commoditization of advanced technology makes its slow and steady creep forward.

So we had an idea:

What if we could outsource a lot of the mundane tasks associated with application development projects to software, rather than handing that work off en masse to a team of strangers in Elbonia?

This notion of project automation is far less “Science Fiction” than it appears. We’ve already seen this shift in the quality assurance space. The impact that xUnit testing and Continuous Integration have had on software quality is game-changing.

We believe that similar improvements can be realized in some of the other qualitative aspects of project management, by making the automation software “feel” less like a software package and more like a person working offsite.

There’s a concept in literature known as Anthropomorphism, which is defined as ” Attribution of human motivation, characteristics, or behavior to inanimate objects, animals, or natural phenomena.” We applied this same concept to software architecture (as many others have before us), building out small autonomous programs, or “Bots”, that we gave names and job descriptions to, and configured them to show up in our Instant Messaging buddy list.

We developed these bots in a way that we could chat with them in English via standards-based Instant Messaging (IM), but they also understood how to talk to other software such as email, web servers, etc., (largely since we’ve built our applications atop Twisted). This approach has also proven to be an interesting means of managing application complexity.

We’ve done a ton of cool stuff with bots, most of which is behind the scenes, and some of which is teed up for future releases of ProjectPipe, and/or other applications that we have in our pipeline.

At the end of the day, Botonomy’s mission is to help small teams solve large problems. Our Bot-based architecture offloads some of the heavy lifting from team members, so that the team has greater autonomy in terms of their options for reacting to change. In contrast, a team with no bots and lots of offshore resources is far more encumbered should they need to turn on a dime. A bigger team usually means fewer choices.

As a small team ourselves, we’re eating our own dogfood every day. We use all of the software that we write, and we managed the development of ProjectPipe using ProjectPipe. We also have bots performing a handful of backoffice functions.

The verdict: So far, so good.

Here’s ours:

At Botonomy, we create solutions that help small teams solve large problems

This catchphrase-based mission approach has three immediate benefits. First, it provides a basis for judging whether or not your various signals and messages to the marketplace are internally-consistent. Everything you say and do should be easily traceable back to this single sentence.

Second, it provides a means to hint at the businesses in which you’re not explicitly engaged or pursuing. For example, we’re not casting ourselves as an “Enterprise” software firm, although there will be clusters of folks in large companies that will immediately “get” what we’re doing with ProjectPipe and find the featureset and integration that we provide uber-useful. We’re also not focusing all our energies on the small-to-medium business segment, although the infrastructure-on-demand aspect of a hosted app is very appealling to those with modest IT budgets.

By explicitly focusing on “helping small teams solve large problems”, we’re defining our core target market as “small teams”, with far less emphasis on the size of their greater organization or specific industry affiliation.

Lastly, keeping it to a single sentence means that you have to leave non-differentiating stuff out. A single sentence doesn’t provide too much room to discuss “customer service”, “shareholder value”, “operational excellence” or the like.