Start ups are for everybody

I came across Dan Crow’s insights into startups and older workers this morning, and I couldn’t stop myself from nodding in agreement through out the article. Part of it, surely, is that I am now closer to 40 than 30. But everything he says about the value of spending time with family, the pointlessness of working grueling hours, and the skills that come from experience had an air of “I’ve been there”.

Many startups, especially in Silicon Valley, have a macho culture of working extremely long hours. I vividly recall a long stretch of consecutive 100+ hour weeks at Apple early in my career — which came on top of a 3 hour commute to San Francisco. The quality of my work noticeably declined, and it took me months to get my focus and energy back afterwards.

It seems that both corporate america and silicon valley startups, while vastly different cultures in almost every regard, still see people as expendable resources that can be used up and replaced. Sure, if you’re working non stop for a startup, you can tell yourself that there’s a huge payoff at the end, or the chance of it. But the risk is that you spend your 20s and early 30s working forever without much to show for it. That was never something I wanted to do, and I’m lucky that I didn’t have to, either.

Why startups shouldn’t just be for the young


More programmers != more productivity

Carl Erickson observes that a small, boutique team of developers can be massively more productive than a larger team.

To complete projects of 100,000 equivalent source lines of code (a measure of the size of the project) they found the large teams took 8.92 months, and the small teams took 9.12 months. In other words, the large teams just barely (by a week or so) beat the small teams in finishing the project!

Its immediately reassuring to see those numbers, since I’ve been on enough projects that, once they start falling behind, the temptation to throw more programmers at it grows. Project managers see it as a resource scarcity problem (not enough programmers) and don’t realize that coordination and communication burden that they adding by bringing more people on to a project. Now you have a new group of programmers that need to be brought up to speed, learn the codebase, and accept design decisions that have already been made. You’re lead programmers won’t have as much time to actually program, since they’ll be helping bring everyone else up to speed. Developers have known about this for years, Fred Brooks wrote the book in it – The Mythical Man-Month.

But while the study’s conclusion is reassuring, I wonder if there are other factors at work. Theres an obvious selection bias in the type of people who go to work at a large IT programming department/shop versus those who choose to work solo or in smaller teams. Are large teams filled with junior 9-5 programmers who just want a steady job but punch out in the evening? Do smaller teams attract more experienced and productive people who prefer to work smarter rather than harder? From the study summary, it doesn’t look like they considered this aspect.


Frustration with Drupal core growing

When a prominent developer and contributor lashes out that Drupal is in dire straits, you better listen.  You ought to read his critique of how Drupal core development is stalling, or at least stuck in the mud.  That can’t be good news for anyone looking to upgrade to Drupal 7.  My thoughts after the quote.

In addition to the half-baked, single-purpose product features mentioned above, Drupal core still carries around very old cruft from earlier days, which no one cares for. All of these features are not core functionality of a flexible, modular, and extensible system Drupal pretends to be. They are poor and inflexible product features being based on APIs and concepts that Drupal core allowed for, five and more years ago.

Where would Drupal be if they had worked more closely with the PHP community early on?  I have no idea, but a lot of PHP programmers have looked down on Drupal because most of the codebase can be messy, with poor API design decisions, overuse of globals, and leaky separation of concerns. Along with Drupal eschewing Object Oriented Programming and resulting best practices, its no wonder that talented developers would choose to use a framework like Zend, Symfony, or Cake to build a complicated website.  It sounds like a lot of short cuts and idiosyncrasies are now baked deep into Drupal core, and ripping them out too much work for core developers.

I’ve always thought that Drupal’s greatest strength is certainly not the great design of its codebase, but the Drupal community and ecosystem. A contrib module usally exists for many common website needs, like managing redirects, creating useful URLs for content, integrating with analytics,  and plugging in 3rd party commenting systems.  On top of that, there are super-modules like Views, Panels, and Context, which let you prototype and build parts of a website without having to write any code at all.  The Drupal community has solved a lot of problems through determination and individual brilliance, but that model can’t be sustainable in the long run.

Is there a solution?

Drupal core should cater to programmer’s needs, via coherent APIs and pluggable subsytems.  A complete rewrite of core, or even big parts of core, would be a waste of time. Drupal would stagnate while other frameworks kept improving.  I think Drupal 8 should seriously consider using a framework like Symfony2 as the foundation for core.  I mention Symfony because it has an EventDispatcher component that can replace most of Drupal’s magical hooks system.  The next release of the Zend Framework will have a similar component. A tested framework, used not just by content management applications would expose developers to a wider range of best practices, particularly around configuration management, deploytment, and unit testing.

Contrib should cater to site builders needs and focus on adding features on top of core that they want.  Modules in contrib can improve faster to meet user needs, fix bugs, and innovate.  This is an idea proposed in the discussion linked above. Moving as many modules as possible out of core also makes Drupal leaner.


What’s in your Project Management toolbox?

Matthew at DogStar describes his PM toolbox today, The Project Management Tool Box | Opensource, Nonprofits, and Web 2.0.  It’s a detailed and well organized list, and I think reflects a very practical approach. The first thing that strikes me, is the overwhelming amount of tools available to the would-be PM.  Certainly, there is no lack of tools out there.

You see, the general feeling is, there is no silver bullet. There is no grail of a tool that does everything a single Web Producer, Project Manager, Product Manager, or Content Manager might need or want. There is clearly a gap that is filled with a series of different products. This walked hand in hand with a desire to review processes at work and engage in course corrections. It is an excellent habit to follow – look what you are doing with a critical eye, analyse why you are doing it, and make changes as needed. I have worked across four different shops with a wide variety of different ways of practicing project management. I have used these methodologies and tools across ~ 50 different Drupal projects and another 25 or so custom PHP MySQL projects.

I could not agree more that its important to not be seduced into picking the one right tool for every situation.  It is a difficult tempation to resists, especially when you have tool makers pushing to sell you a solution. The best tool for the job isn’t the one that has the most features, its the one that you, and your team, end up using the most.

As I read the article, a thought that struck me is that sometimes, you don’t need ONE tool, you just need to make sure everyone has the right tools (and skills) to be productive and responsible. At work, we’re a tiny team of 3 who deal with day to day management of our Drupal site, unexpected requests on tight deadlines, and long term projects to build new features. Here’s a secret – we don’t have a central bug/ticket tracking tool. We can be productive simply with email, IM, code bearing, and face to face conversations. For big projects we use a whiteboard to wireframe, capture tasks, and track progress.  This works better than a more sophisticated technical solution that would impose a greater burder on our time.

What’s your experience with tools and grappling with finding the perfect tool?


Make them Interact!

The more that a team can interact and iterate, the better you're final product can be.  In my ideal world, I'd skip a detailed wireframing exercise and get to building a prototype as soon as possible.  Its so much easier to explain what is difficult to build if there's something to click on.  Or you might learn that what you thought was hard turns out to be easy, or vice-versa.  Finally, if you already know if you are using Sharepoint, Drupal, or anything else, you're front-end designer has to know assumptions the platform makes, how it manages content, and other implementation details.

In my practical experience, I find that teams are more efficient when roles overlap and people understand what is happening outside of their silo.

Developers and Designers « Content Here


American Soccer News » Lead Story » Garber talks tough on CBA

I really, really hope that it doesn’t come to a work stoppage. As in most labor negotiations, it seems like a lot of posturing on both sides. The players really don’t have a lot of leverage without threatening a strike or stoppage. Let’s hope both sides don’t get too close to the brink that there is no turning back.

I guess the cat is out of the bag now. This is something I get to work on in the off-season, a new digital platform for the league and its teams. If only I could travel back in time 8 years to tell myself I’d be working on this.

MLS will roll out a new digital initiative for the start of the 2010 season, in partnership with Microsoft, among others. “The media landscape continues to change,” said Garber. “We know the platforms and outlets are changing…we will be very committed, very innovative and very supportive of the new digital environment.”

Garber talks tough on CBA


Multi-tasking is a myth

I’ve been finding that maintaining a fairly accurate todo list has helped me concentrate on finishing tasks and avoiding “multi-tasking”. I really like Hiveminder, an online todo list manager. It’s really easy to enter tasks – you can just type something like “Post article about multitasking on bloc [due Wednesday][blog]” to create an item that is due the next Wednesday and tagged “blog.”. You can even use this syntax over IM, which I’ve found really helpful for capturing requests that come in throughout the day but then turning my attention back to what I’m working on. Stanford study: Media multitaskers pay mental price

People who are regularly bombarded with several streams of electronic information do not pay attention, control their memory or switch from one job to another as well as those who prefer to complete one task at a time, a group of Stanford researchers has found.

Real Life

What I learned from Jon & Kate plus Eight

Or, learning to love process/order and prevent chaos

TLC’s show Jon & Kate plus Eight has both of us hooked.  We started watching after we learned we were expecting Nicholas, partially in a funny "At least we don’t have eight kids" way.  But the show is entertaining, and has given us a couple of clues about being parents that might be helpful down the road.  Nothing super revelatory, but stuff that is good to hear again.

oWatching the recap show about parenting, Kate said something to the effect that "Without order we’d have chaos and then the kids would rule the house."  Specifically, both of them talked about how important it is to keep a very regular schedule for the kids.  So that, for example, they know that noon is lunch time and its time to be quiet and sit at the table.  Of course, as the kids grow they may try to disrupt the schedule, but the every day routine is key to keeping their household running day-to-day.  Not just operating, mind you, but operating so that the parents aren’t over stressed and so that the children also learn how to behave and develop good habits.

Meanwhile, I’ve noticed myself at work becoming much crankier about people not following processes or making up for a lack of organization with "urgency" and hustle. It’s not that I don’t appreciate that, as a client focused services firm the need to be flexible.  Its that, as a programmer, although this goes I think for any role at work, I have a number of client projects that require my attention on any day.  The "little" tasks and tweaks that push themselves to the top of my queue come at the expense of  attention to other client requests.  And when a particular task, like debugging a broken site or implementing a new feature, requires by necessity a good, uninterrupted stretch of time to focus on it, the disruptions are even more magnified.

What am I asking for?  At the core, I’d like to not have tasks dropped in my lap at the last minute, which are urgent because adequate planning was not done to get them assigned and worked on.  I’d also like people to actually follow the recommended best practices for Task delegation, Resource planning, and Bug tracking.

Does this mean I think any of my co-workers are childish, or immature, or somehow not competent.  By no means.  I’m merely saying that work could be a lot less chaotic and stressful if we all were disciplined about sticking to agreed upon processes.  Am I perfect in this regard?  Hardly.  There are a lot of habits I know I need to work on to get better at, particularly in avoiding distractions at work so I’m not wasting time on less important, but sometimes personally more interesting, tasks.


Management Anti-patterns

Sandy sent me a link listing anti-patterns as applied to management practices. For those not up on the jargon, an anit-pattern is a bad practice that is repeated frequently. I first heard this term in terms of programming patterns and anti-patterns, but I’ve since heard it used in non-programming contexts. I can honestly say I’ve run into the Hard Code anti-pattern, code-momentum, cargo cult programming, and bug maganets, to name a few. I’ve also commited Accidental complexity, magic numbers, monkey work, and parallel protectionism as I’ve learned to be a better programmer.

The management ones would be funnier if they weren’t so true. The ones that hit close to home for me are Hostile Testing, Napkin specification, Seagull Management, Leader not Manager, Scope Creep, and Design by Committee.

Anti-pattern – Wikipedia, the free encyclopedia

Often pejoratively named with clever oxymoronic neologisms, many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible. Sometimes called pitfalls or dark patterns, this informal use of the term has come to refer to classes of commonly reinvented bad solutions to problems. Thus, many candidate anti-patterns under debate would not be formally considered anti-patterns.


Linux Package management overview

I have to confess that delegating software installation to Debian and Ubuntu’s apt command is what finally converted me to Linux.  I stillhave a bias against .rpms and building from source based on disastrous experiences hunting down obscure .rpms or figuring out why make would not work.  If you’re trying out Ubuntu or another Linux distribution, you should stop and read download squad’s Package management 101

Package management refers to the way your distribution installs and configures (as well as manages and removes) software applications and libraries on your system. When Windows installs an .exe (which is the closest thing in Windows to a package) it usually places it in a single specific place within a directory. Linux installs across a few directories, leaving many new Linux users scratching their heads as to where their .rpm actually went. Most distributions install the executables in /usr/bin, and the libraries in /usr/lib. You may notice related files in /usr/share or /etc.

In short, you’ll want to let your package manager install and upgrade new software for you.  You don’t have to take my word for it, Thank You, Aptitude!

I’ve long believed that the easiest way to install software on a modern operating system is through a well-designed package manager connected to one or more carefully-maintained package repositories.