“As long as each user sees the appropriate design, the choice between these implementation options should be an engineering decision and not a usability decision.”

–Jakob Nielsen (emphasis added)

You can read the article here.
http://usability.com/2012/04/24/compromise-happens/

I feel a bit bad picking on this release of Basecamp because it is such a well made application.  It is beautiful and fun to use.  Quite honestly, I probably feel so strongly about the release because it is so nice to use I *really* want my co-workers to embrace it.  But I fear the feature decisions will prevent us from moving away from Basecamp classic anytime soon.

And that got me to wondering about the way 37Signals made their decisions about various features.  On one hand, their method of feature selection is pretty clear.  They “eat their own dogfood.”  That is, they build Basecamp for themselves.  So, it makes it a pretty open-and-shut case when users like me complain about missing features.

Their opinion, since the first Basecamp rolled out the door nearly a decade ago, is that they would rather Basecamp work great for the audience that works like they do than to add features that they don’t understand or value just to make a few more (hundred? thousand? million?) people like it.  People have complained about this standard for years and their success says that the standard works.

On the other hand, I’m still struggling with things that exist in Basecamp classic that didn’t make the move to the new Basecamp.  Primarily, this involves the decision not to support private messages and to not include time tracking.  37Signals has openly addressed the time tracking decision and I applaud them for their attempts to address the outcry.

But something struck me about the situation this past week.  I had just finished watching a video showing some advanced tips and tricks for the new Basecamp and then I soon discovered that these two near and dear features were not included.  One of the tips was that they’ve added hot-zones in the upper and lower margins of the application.  When double-clicked, these invisible zones cause the browser to scroll to the top and bottom of the page.

Neat!  Totally not necessary, but very neat.  Of course it is completely not evident unless somebody tells you.  It would fail a usability test because there is almost no discover-ability, but neat and polished none-the-less.  And then during the live demo, I saw the speaker gleefully fill every message with Emoji emoticons.

And that’s when it hit me.  How can you have time to add the spit-and-polish that is evident in Basecamp and not address features that are critical to converting users to the newest version?

Obviously, adding emoji support did not take as long as it would take to add time tracking so it’s not a direct one-to-one comparison.  But if the team were sitting around looking at a backlog and they were debating adding secret, hidden, double-click hot zones and emoji support versus adding time tracking, how in the world did they choose those two shiny things over a feature with clear business value?

And then I realized I was comparing apples to oranges.  In my head, Getting Real is synonymous with Agile Development and I typically replace “agile” with “scrum” since it is the most common agile methodology in my experience.  But the Getting Real paradigm doesn’t have to work from the same parameters.

Release early, make a decision, etc. does not always mean put business value first.  Having time tracking in the product adds business value even if nobody uses it.  Why?   Because it helps meet the checklists that people, especially the budget people, have in their heads for what project management tools should do.  It makes it easier to convince people that the tool, as simple as it looks, really will be flexible enough to meet your project needs.

Note: And to be clear, I’m specifically thinking about the people you have to convince because they write the checks, not because they will use the application.  That’s just the reality many of us live and work with in the real world.

And the same goes for the private messages.  My guess is that the 37Signals team hated that feature.  Usage was probably even lower than the time tracking feature and it just doesn’t feel right to them to not communicate everything in the open.  That’s my guess anyway.

And I agree with some of that logic.  My co-workers rarely use private messages.  But every darn one of them has asked me about the feature before they agreed to use Basecamp (classic) for client work.

I’d like to believe a quality scrum team would have made different decisions when choosing the features for Basecamp.  But I also can’t shake the feeling that Basecamp wouldn’t be as fun to use if that’s the way they made decisions.  Would you get all of the little touches if you evaluated your feature list based upon a “value” column?  You can clearly define a value of those touches, but would it win out?

I don’t know.  And again, I’m perplexed.  The new Basecamp continues to perplex and confuse me.  I get it, I love it, I want to use it, but I’m not sure I can ever get my co-workers to buy into it as is.  So, does that make the shiny touches worthless?  It feels that way sometimes.

Okay, how can a feature work too well?  Please, let me explain.

Loop ‘em in

The idea of “loop-in” is that you may create a discussion in Basecamp and essentially carbon-copy the message to an email address that is not part of the Basecamp project.  When I sat in on one of 37Signals excellent live demo’s this past week, the scenario went something like this:

• You need some graphics for the project so you’d like to send an email to a contact at a design agency to ask them if they can contribute to the project.
• You create a discussion in Basecamp and use the “loop-in” feature to add the designer to the conversation via their email address.
• You write the discussion/post/message just like an email to the person in question.  Something like:

John,

We could use your help with the logo on the BCX project.  Are you available next week to discuss?

Thanks.

• When you submit the discussion, an email is sent from Basecamp to the looped-in person on your behalf. 
• The person is never given access to your Basecamp account.  They just receive an email that includes instructions to reply above the line.
• When they reply, their response is added directly to the Basecamp discussion.
• Your entire exchange is fully documented for the current and future benefit of the team.

And the problem is?

For the purpose that it is designed, this feature seems to work great.  It really improves the ability to track all related conversation within the project.  You no longer have to add a person to the entire project just to communicate with them in a tracked way.

And you avoid the sometimes clunky procedure of CC’ing a message into Basecamp when emailing an outside person.  This latter technique tends to miss the reply which typically only goes into your email inbox.

The problem is that people don’t always treat email messages as single-subject or single-use things.  And while the message is clearly marked as being via Basecamp, that might not mean anything to the person reading your message or they may simply not read it carefully enough to know that they are talking to you indirectly.

Two things that happen frequently with email are problematic for this scenario.  First, the message in reply often doesn’t stay on subject. I’m replying about project X, but I may mention a completely different project that we’ve discussed.  And now that conversation is shared with anybody and everybody in Basecamp that may have access to the project.

Second, people tend to use the last email from you as the quickest way to start an email to you later.   How many times have you seen somebody reply to an old message with a completely different topic.  You know it happens all of the time.  In both cases, your Basecamp project now has private or off-topic information that should not have been shared with the rest of the team.

How frequently will something like this happen?  I don’t know, but I do know this is exactly what happened the very first time I used loop-in.  The person I sent it to replied to my question perfectly and the response went right into Basecamp and was instantly shared with the rest of the team as I had hoped.  We actually bounced the discussion back-and-forth over several “emails” between us.  Me using Basecamp, him using Outlook.

And then came the fateful reply.  ”Oh, also, could you look over these numbers I’ve put together for Project Y?”  And there, attached to the message was an Excel document with numbers that were not intended to be shown to the rest of that team in a document talking about a completely different client.

Thankfully, since this is a trial of the new Basecamp, I had not included any clients on the project and so nothing was shared outside of the company.  But when I informed my co-worker of what had happened he was pretty shocked and worried.

And I was quickly convinced that loop-in is probably not a good idea for us.  And that’s a pity, because it is a well executed feature.  But I’m concerned that it really works too seamlessly and it shares things too publicly, too easily.

And the fateful problem is?

So, does it matter that loop-in could backfire on you?  If loop-in were simply added to Basecamp Classic, I would not worry much.  You could just use it judiciously and be very clear in your messages regarding the forum of the discussion. But the new Basecamp has removed the ability to mark specific messages as “private.”  Which means the only way to include a client into Basecamp without giving them access to everything is to only loop-them-in on specific messages.

This is probably the most perplexing feature decision that 37Signals made with this release.  And it makes it extremely important that looping-in works perfectly.

Given the obvious flaw in the system, I’m not sure what to make of the new Basecamp.  It is beautiful and well executed.  And yet the feature decisions put us in a really difficult place.  I hold little hope that I can convince my co-workers that loop-in sufficiently makes up for the missing “private message” feature.   Just knowing that the feature was there made it an easier sell internally.

Now?  Now I’m trying to warm up again to Basecamp Classic.  Uhg.

The Name

This week we got “The New” Basecamp and The New iPad.  It seems to be an odd choice for both Basecamp and the iPad.

In theory, this works better for hardware.  The 37Signals guys were quick to point out that Honda rolls out a new Civic every year and they don’t name them the Civic HD, Civic 4S, etc.   You just get a new Civic.  But the car industry has the decency to put a model year on it.

Comparing iPad Models

Apple’s been playing this game for a while.  I own a white MacBook and 95% of the time the actual name of the model doesn’t matter.  But when it does matter, I have to know that it is the 13-in Early 2009 MacBook.  I suspect “the new iPad” will have the same issue.  This is because this image to the left won’t help you much in 2014 when you are trying to get support and they need to know if you have an iPad 2, a 2012 iPad, or a 2013 iPad or whatever.

But with Basecamp, the name game feels even more strange.  What we once knew as Basecamp is now Basecamp Classic.  And this new thing, with a completely different feature set has assumed the Basecamp name and is generally prefaced with “the new” to differentiate it.

Why the name games?  Did Ryan in The Office completely ruin the ability of software companies to name their product “two-dot-oh”?

The most straightforward answer seems to be this:

• Unlike Fog Creek with Trello and FogBugz, 37Signals wanted to leverage the brand value of their existing product with their new, created-from-scratch product.  Where Fog Creek has created a second project management tool to live along side their existing tool, 37Signals is maintaining the brand name with the new product.  Think: New Coke.  Oh wait, maybe that’s not the image they desired.
• However, unlike most upgrades (excluding Apple’s treatment of video editing software) this “upgrade” actually removes several previously “key” features.

A major release like this is going to upset many users however you do it.  If you position it as Basecamp 2.0 and you remove key features, well, users are going to freak out.

So, the team at 37Signals appears to be trying to walk a fine line.  The new thing is new and different, but not the same product at all.  So, you get the old thing renamed and a few Jedi mind tricks later… everybody is going to be okay.  In theory.  But this feels like a decision they will regret if for no other reason than they are going to get tired of talking about it.

No Auto Upgrade

Another complication is the decision to not auto-upgrade users to the new Basecamp.  Instead, your current projects and accounts may continue to live on forever (or some version of forever) in Basecamp Classic.  You may give the new Basecamp a whirl via a free trial and import your projects over, but you don’t have to do so.

Why would anybody stay in the old version of a product if the new version is available for essentially the same price?  (Let’s ignore the issue about no longer supporting a “free” version in the new Basecamp.)

This isn’t a decision that was made by accident.  There is a really good reason, but it’s going to frustrate a lot of folks.  You see, the new Basecamp really is a brand new product.  Completely new code, new features, new style, and all the things that go with a new product.  Being a new product, the new Basecamp has a limited feature set.

Yes, there are new features that Basecamp (classic) never had.  But there are features that are missing.  Some are quite intentional (no private messages!) and some are more complex (no time tracking!).

Tangent: When Salesforce rolls out a new release (three times a year) you rarely lose key features.  And if something is going to change, there is significant build up to the event that includes transition guides, the works.  If this winter, Salesforce rolled out a release that say, removed the Opportunities object then all hell would break lose.  You don’t just auto-upgrade users to a version of your application that does not include key functionality they have previously enjoyed.

And thus, 37Signals put themselves in an awkward situation.  Or, more importantly, they put their users in an awkward situation.  You can keep on paying the same price for eternity for the old tool that they are not likely to enhance ever again, or you can move to the new application with a different feature set.

Good luck on convincing your budget guy of option one and good luck of convincing your users of option two.

Getting Real and New Coke

Okay, New Coke is an unfair analogy.  The legend of New Coke is that of disaster.  The new Basecamp is not a disaster.  It is a great little application.  But it is not a slam dunk for existing users.  And the 37Signals crew is smart enough to know that.  Thus, the name game and leaving everybody in the old “classic” version.

If 37Signals has made a mistake here, I think it is in the decisions they are forcing customers to make.  I admit that it has been a while since I’ve read the Getting Real and ReWork manifestos.  A key element of Getting Real, as I remember it, was Configuration over Customization.  In practical terms, making the tough decisions for your customers instead of presenting a bunch of options for them to twiddle with and a bunch of decisions for them to screw-up.

The New Basecamp, unfortunately, leaves their customers with a lot of uncomfortable decisions.  A few of these include:

• Do I give up private messages?
• Do I give up time tracking?
• Do I have to evaluate the time tracking market along with the new Basecamp?  I can’t choose one without the other.
• Do I import my active projects to the trial knowing that I can’t re-import my changes to the classic version if I later decide to go back?
• Do I kick my clients out of my projects and only “loop them in” occasionally?
• Or do I leave my clients in the project and expose them to everything moving forward?
• How do I communicate to my clients where to login in the future since the URL changed?  What if I decide to go back to Classic?

37Signals says they’ve been working on this project for nearly a year.  They did a great job.  It is a sweet looking application.  They asked me to give it five minutes.  I’ve given it two days thus far and will certainly continue to try to make it work.  But the bar is raised for a release of an existing, successful application.

This version of Basecamp feels like it should still be in an early private beta until it was ready for “all” of the users.  Then all of these decisions could be eliminated.  And let’s define “all” as being enough of the users that 37Signals didn’t feel the need to maintain Basecamp Classic.

Getting Real with the new Basecamp, in my opinion, would mean eliminating most of these decisions.

Otherwise, it should be called what it is, a different project management tool.  And it shouldn’t masquerade in the Basecamp name.  It feels like there are hundreds of Basecamp knock-offs out there already and in some ways The New Basecamp is another knock-off.   Perhaps it is actually better, but it is not the same application.  And because of that, we the users face a lot of decisions.

The Future of Classic

In theory, if you are like me and you don’t expect your team to buy into the new Basecamp because of the missing features then Basecamp Classic should be just fine.  The whiners should just deal with it and go back to enjoying what they had before.

But the world isn’t that simple.  My iPad 2 feels clunkier and less satisfying today because I’ve seen the new iPad.  My customer satisfaction has decreased even though the product still rocks.  Basecamp Classic feels the same way.  I’m less satisfied with Basecamp Classic today.

It will be interesting to see what 37Signals does with this problem.  The near-term plan appears to be to do nothing with Basecamp Classic.  Leave it running, keep answering support messages, and apply minimal updates to keep it safe, secure, and performing acceptably.  Long term?  How many customers will stay with classic and not eventually take their business elsewhere once they’ve had time to re-evaluate the market?

Will the price of Basecamp Classic eventually go down?  That would certainly help deal with the user satisfaction issue.  The iPad 2 got cheaper this week, for example.

If Basecamp Classic’s usage finally drops low enough, would 37Signals open-source the code?  That would be interesting though I don’t know if it is practical.

My hope?  I hope that my co-workers and I come to love the new Basecamp so much that I stop caring about Basecamp Classic.  Every guy gets to have a dream, right?

And to that end, I guess it works. Consider this sample snippet from Wikipedia’s article on foobar (http://en.wikipedia.org/wiki/Foobar)…

/* C code */

#include

int main()
{
   char foo[] = "Hello";
   char bar[] = "World!";
   printf("%s %s\n", foo, bar);

   return 0;
}

It works and any semi-competent programmer will understand your code example.

On the other hand, when “foobar” is used in programming books and introductory programming texts, it promotes poor programming habits in the reader’s real code. And I think your audience is very often the inexperienced, impressionable programmer. Using “foobar” in your code samples teaches young programmers the wrong things about naming routines and variables.

Good names for routines and variables makes code easier to read, to maintain, and to know when to refactor. Steve McConnell’s classic book Code Complete offers the following suggestions for good routine names:

1. For a procedure name, use a strong verb followed by an object
2. For a function name, use a description of the return value
3. Avoid meaningless or wishy-washy verbs
4. Describe everything the routine does
5. Make names of routines as long as necessary
6. Establish conventions for common operations

Foobar, obviously, violates pretty much all of these suggestions.

The problem is that it takes some effort and creativity to produce a code example that uses something other than “foobar” without creating a distraction in your example.  Eventually, it becomes a crutch in your writing and your code.  And less experienced programmers see these examples and follow them like gospel.

If the example is worth writing, then it is worth using good programming practices throughout the code. Your code examples say a lot about your work and ultimately “foobar” says that you couldn’t come up with a real example.

“80% of all usability issues are ‘duh’ issues.”

Matthew Lamb (@SFDCMatt) – via @klrichardson

Are ‘duh’ issues ruining your product?  Do you even know about the ‘duh’ issues in your product?  If you are not usability testing your site with real users you are likely missing a lot of easy things that you could fix.

It’s the ‘duh’ issues that cheapen the experience of so many applications and websites.  We users can tolerate a lot when it comes to problems that are obviously difficult or expensive to fix.  How else do you explain consumers’ tolerance for horrible mobile phone service?  But the ‘duh’ issues are another matter all together.

If your product is full of ‘duh’ issues, it says you don’t care.  You can uncover a lot of these issues if you will take the time to do usability testing with real users.  You will find yourself facepalming when you realize how many “obvious” things you didn’t see yourself.  But many times these issues are just a matter of lazy developers.

I believe that ‘Duh’ issues are far too often the result of lazy programming.

For instance… Have you ever seen somebody struggling with a smart phone to complete a web-form and told them “if the programmers had designed that form correctly, your phone would automatically change the keyboard to make it easier to enter your email address?”  I distinctly remember telling my wife about this.  She asked “So, the programmers were just too lazy or incompetent?”

Now, when she finds an issue with a site she’s likely to ask me “is this because of lazy programmers?”  Far too often, the answer is ‘yes.’

This week I saw an apparent example of lazy programmers from a source that surprised me a little bit.  Google.  Here is a company with more smart people than you can shake a stick at.  Yet, take a look at the screenshot below.

Know what you know

Come on Google!

Your application should know what you know!

Yeah, I’m being picky.  But we’ve been writing software for decades upon decades.  Shouldn’t our software KNOW what it already knows about the users?   In this case, Google knows:

• That I have a Google Account
• That I’m logged in
• That I have a Google+ Account

Why then, is it inviting me to join Google+?  And before somebody starts giving me a technical explanation let me just say that the technical problems or costs aren’t my concern.

I’m a user.  I don’t care if Google’s search page, Google’s black bar, and Google’s “plus network” are all different units run by different people on sandboxed systems and one’s in Python and the other is Java and the other is Node.js or whatever geek speak you want to throw at me.  Users don’t care.

What users see is an application that, at the top of the screen, knows about my Google+ account and a half-inch down the screen it has no idea about my Google+ account.

Know what you know.  It’s a slogan Yogi Berra would love.  And I believe we can make better applications and better user experiences if we keep that in mind.

And as a follow-up note to this topic… Reed Hastings, you can try to avoid this little issue by re-branding half of your application.  But users know that Netflix is Netflix, no matter what you call the DVD service.  And it will always annoy them that half of the app doesn’t know what the other half of the app knows.

You can give all of the business and technical reasons you want.  But users don’t care.  We know that you are choosing to design your application so that it doesn’t know everything that it really knows about our accounts.

This week I’m left wondering if a software company is “done” when it starts releasing products that compete with itself. Google has had me a bit confused with Chrome OS and Android for a while. But this week things hit closer to home for me when the makers of FogBugz, a project management tool, released Trello, a project “organization” tool.

Project Management Pegs

I’m a big FogBugz fan. Heck, I even wrote a blog about it for a while. I’ve promoted FogBugz at work for years and I’ve used it for personal projects many times. I’m in the software dev world, so a tool like FogBugz is essential for almost every project. However, I’ll be the first to admit that FogBugz is not for everybody or every situation.

I’ve tried lots of other project management tools. I’ve used some “agile” tools like Pivotal Tracker and Rally. Recently, I’ve pushed BaseCamp strongly for lots of teams at work that needed something different from FogBugz. And I’ve tried various kanban tools like KanbanPad.

So, when I load up Trello for the first time I’m not trying to squeeze a square peg into a round hole, but I also recognize a square peg when I see it. Trello is clearly a project management tool in the spirit of kanban (kanbanpad, leanitkanban).

Why Trello?

Okay, I’m cool with that. Maybe they’ve made an electronic kanban system that works. But wait, why is Fog Creek producing two apps in the same market? Why is one of them free and the other one is charging $25 a user a month (for the hosted version)? And why isn’t FogBugz getting some of these features?

So, I go back to the source to see what Joel Spolsky has to say about the release of KanBugz, err, I mean Trello.

“After ten years in management I still never knew what anyone was supposed to be working on. Once in a while I would walk around asking everyone what they were doing, and half the time, my reaction was “why the hell are you working on THAT?” So one of the teams started working on finding better ways to keep track of who was working on what. It had to be super simple and friction-free so that everyone would use it, but it had to be powerful, too.”
Joel – JoelOnSoftware – emphasis mine.

So, Trello (man, I like KanBugz, do you mind if I call it that?) lets you see “who was working on what.” Really? I think like most project management software, what it really lets you see is who is SUPPOSED to be working on what. What feature shows you what folks are really working on at the moment?

Okay, it actually does have that feature! It’s the “Activity” feed, or board, or panel, or window, or thingy on the side of the screen. Whatever they call it. And that feature seems to work okay, based upon my initial experiences. The allocated area is a bit narrow, but it works.

But all the other stuff, the cards flipping and dragging, the lists, the boards, etc., all of that stuff doesn’t tell you what anybody is actually doing.

And I have to wonder, doesn’t the FogCreek team live in FogBugz already? What are they using internally now? Trello or FogBugz? Because FogBugz already has the features that you need to run a project and to know what everybody is working on.

Working On

The “Working On” feature in FogBugz literally let’s one identify exactly what they are working on at that moment. If that’s not enough, Working On provides time tracking and provides the raw data that powers Evidence Based Scheduling.

"Working On" Feature in FogBugz

There is a drop-down labeled “working on” in FogBugz that lets the user, very easily, identify what they are currently working on and how long they think it will take.  This feature is very smart.  It adjusts for your lunch schedule and your normal beginning and ending of the day.  So you don’t have to micromanage the app to accurately record the key activities of the day.

FNN – FogBugz News Network

So, maybe your users refuse to enter estimates or indicate what they are working on during the day.  That’s okay, if they are doing anything with the project management software, like opening, re-assigning, or resolving cases, then everything gets recorded and can be reported.

FNN is a nifty little FogBugz plugin that, wait for it, tells you what people have been doing. Here is a quick screenshot of the plugin in action:

FogBugz News Network

Kanban Plugin

And just to be clear, you can kanban in FogBugz. (say that 3 times fast). There is a plugin for that too!  Kanban boards are useful in software projects and they are available for FogBugz.  The Kanban plugin provides a nice little board for your card sorting pleasure.

Kanban Plugin for FogBugz

So, About This Trello

I’ll be the first to admit that FogBugz is not perfect. But Joel’s claim that he didn’t know what his employees were working on doesn’t pass the smell test. He already has one of the best project management tools on the market and it includes specific features for the problems that Trello claims to address.

So, what is good about Trello?

It’s a huge step forward in interface design for Fog Creek. The initial interface of a “board” is simple and well implemented. Drag-n-drop features work well, and like most kanban boards, it provides an understandable high-level view of a project.

Fog Creek doesn’t have the best reputation for building fancy user interfaces.  FogBugz is powerful, flexible, and full featured, but it is not pretty.  Trello shows that they can embrace design at Fog Creek.

And I’ll admit, we are giving Trello a shot at our office.  The R&D team is using Trello to describe high-level projects and tasks.  Essentially, we are using it for release planning.  But we are still managing all of the details and sprints within FogBugz.

Why?  The problem I’ve always had with Kanban boards, both physical and electronic, is that when they get too big they start to lose their effectiveness.  When everything fits on one screen, or one whiteboard, and when each card can hold all of the relevant information at that level of the project, then they can convey a lot of information very quickly.  But when the card gets too full and the board starts overflowing, then the metaphor starts getting in the way of actual project management.

Take a look at the Trello Development Board for example. It’s an impressive example of eating your own dog food.  But at the moment, there is something like 36 cards in the ideas column and I can only see about 5 cards at a time on my laptop screen.

Trello Development Board

And then you flip a card over and things really get messy.  For example, this is part of the back of a card about sorting cards:

Back of a Trello Card

Buried somewhere in that list of over 100 votes that scrolls forever, you will find almost a dozen comments.   And that’s on a card that can be described in 6 words.  I don’t have many cases in FogBugz that are only 6 words long.

And if you were actually a member of a board, you would see that the right hand side of the card has all kinds of other doohickeys that I haven’t taken the time to figure out.  Let’s just say that the first time I turned a card over it reminded me of the story cards from Rally and I don’t mean that as a compliment.

Project Management for Real People

The frustrating thing about Trello is that I sort of get why they created it.  Back in 2009 I said this about FogBugz:

Perhaps the greatest flaw in FogBugz is built right into the product’s name.  Bug.  FogBugz was born as a software defect tracking application.  It is hard to escape one’s heritage and yet there is a much larger market available that has thus far been out of reach.

http://fogfanz.wordpress.com/2009/03/17/7-and-beyond-glass-half-empty/

Trello seems to be Fog Creek admitting that FogBugz will never be adapted to appeal to a larger market.  And that makes me a little bit sad.

Of all of the project management tools I’ve used, to manage software projects, house projects, blogs, customer support, clients, and co-workers, none of them have made me as happy as FogBugz over the years.  And yet, I know not to use it for certain projects because I know my client or co-worker will be overwhelmed by the density of information.  What works great for programmers doesn’t work great for everybody else.

Clearly, since our own R&D team is trying to use Trello to manage releases at a high-level, even while they live and breathe FogBugz daily, there is a need for this type of view for software teams.

Yet I shudder to think of managing a large-scale software product via Trello.  One look at the Development Board for Trello convinced me that is not how I want to work when we get down to the details of a large project.

Conclusion

I’d rather see some of Trello’s approach integrated into FogBugz than to see more of FogBugz’s features integrated into Trello. And I’d like to hear Joel and company speak the truth about the purpose of Trello and where it fits within their product lineup.  I just don’t buy the “what is everybody working on” story and I’m not sure I like what it says about their long-term belief in FogBugz.

The Scene

Texas A&M wants to join the SEC, the SEC wants A&M to join but doesn’t want to open itself up to any unnecessary litigation, Baylor doesn’t want to give up it’s right to sue, and Oklahoma can’t decide if it wants to stay or go.  And don’t forget that the PAC-12 will want to protect itself from unnecessary litigation before it offers to accept Oklahoma too.

There are a LOT of opinions about this whole mess and a lot of blame to go around.  I’m not interested in the blame game.  The only important question right now is, how much is it going to take to pacify Baylor?

What Does Baylor Want?

There are only three things that Baylor could hope to get out of this situation.

1. To save the Big 12
2. To gain membership in another conference
3. To get some money