I would like the content here to remain and I may occasionally post here when something relevant comes up. But Fog Creek and Joel have grown well beyond FogBugz and it seemed limiting to continue a FogBugz only blog.  So, after a long break from blogging,which was mostly spent being a soccer dad and software guy, I’ve opened shop again at a new blog.  The Deli is a lot more open to varying topics than FogFanz.

The first post there was about money and college football and the second post was about Trello and FogBugz.  Planned topics include Ruby on Rails, Foobar, Usability, and Agile Development.  Unplanned topics will appear as they happen, or not.

Coffee

While many attendees lived in the Austin area, a handful of folks like myself made the trip in from other parts of Texas like Dallas and Houston.  I slipped into town late Tuesday night to avoid key traffic clogs in Dallas and north Austin.  Wednesday morning, I grabbed some breakfast and coffee and then headed over to the conference.

Score one for me.  A tip I picked up from the Boston DevDays Twitter reports: bring your own morning coffee to Dev Days.  After signing in, I got stopped by one sleepy programmer that wanted to know where to get the coffee.  ”Umm, several blocks away at McDonald’s.”  There was plenty of coffee during subsequent breaks, but at check-in you are on your own.  I managed to finish my coffee without being mugged, though that was discussed by the coffee-less programmer.

Tchotchke

While we waited for things to get started, Dev Days sponsors had lots of goodies to give away like buttons, stickers, notepads, etc. but I was surprised to find books being handed out too.

A friend picked up Painless Project Management with FogBugz for free, and I grabbed a copy of Jason Cohen’s Best Kept Secrets of Peer Code Review. I actually already had both books, but now I’ve got a copy of the code review book to share!  [It has already been snapped up by a co-worker.]

Keynote

We finally settled in for the keynote which was kicked off with a funny satire video of Joel basically being Funny Sarcastic Joel complete with programmers forced to run laps through their sparkly office.  Then Joel took the stage with a crazy loud introduction like he was Steve bleeping Jobs or something.  It was a kind of  weird, over the top (and I guess sarcastic) introduction for Joel given his speaking style and general persona.

Joel is always at his best when he is making fun of the ridiculous nature of technology and he did not disappoint with most of his keynote material.  As has been mentioned in reviews of Boston Dev Days, Joel’s topic was the struggle to make software products with the right mix of simplicity and power by avoiding forcing users to make decisions that should be handled by the software.

There were lots of funny moments and a few digs at the “simple” competitors to FogBugz.  One element that stood out to me was his use of 37Signals versus FogBugz as the examples of EASY versus POWERFUL.  His point made sense in context, but given Jira’s everything but the kitchen sink reputation versus FogBugz “it just works” approach it felt like there was an opportunity for a Jira fan to shout out “You Lie!” during that part of the presentation.

It was just a bit weird to see FogBugz listed on that side of the equation.  On the other hand, it is obviously a lot safer (read: polite) for Joel to poke at 37Signals since they are not a direct competitor in most respects.

Much like this review, Joel’s keynote seemed to go on a bit too long.  By the time he was done, the actual point was a little bit lost on me.  I think it was a long way of saying “it is hard to make software that is both easy to use and powerful enough to meet customer demands.”  Working for a usability company, that is a balancing act with which I am very familiar.  It is an eternal struggle, at least for those software developers that even care to try.

Ironically, as Joel finished his keynote the presentation’s were immediately plagued by annoying pop-up messages from Windows as it was struggling to resolve IP addresses on the various presentation computers and VMs.  Several presenters, including Joel, had to futz with error messages like “duplicate name on the network.”  In some sense, Joel’s keynote set the tone for the rest of the day as Windows continued to annoy presenters with messages and questions they didn’t want to see about the basic functionality of the computer.

My guess would be that StackExchange leaving beta might account for one of the four. Kiln, whatever it really is, should also be announced and explained. What other treats await us?

The list of things we think we know about the product is pretty short:

• Fog Creek brought in six interns this summer to build a product ala Project Aardvark that created Co-Pilot 1.0.
• Fog Creek recently began using a beta of the product internally.
• Earlier this year, a Fog Creeker demonstrated a product idea to Joel that he was really excited about… but could be completely unrelated.
• The product name just recently became public knowledge due to Joel announcing a logo contest.   Perhaps the name had been mentioned elsewhere but this is the first I’ve seen of it.
• It is a safe assumption that the “intern product” and the “Kiln” product are the same.
• The product fits within the Fog Creek sweet spot with the goal “to help software developers make better software.”
• They want the logo to “exist in the same universe as FogBugz’s kiwi.”  So, they are likely thinking about a product family or something.  Siblings?  Cousins?  Estranged lovers?
• As late as August of last year, Fog Creek had a software team for a project to build a stand alone Wiki product.   Yes, now I’m fishing.  But it tells us something about the mindset at Fog Creek or at least what they were thinking about a year ago.
• Fog Creek knows that a simple, popular,  hosted application can be a cash cow.  Recurring revenue…  Lower support costs…  Short dev window… all point to a hosted application.

So, what is Kiln?  I haven’t seen any speculation on this subject anywhere.  But I’m not above pure speculation.

Of  the things we “know” I think there are 3  important points.

First, the scope of the product was something that could be completed in a summer by 6 talented but inexperienced developers.  I think that is double the original Co-Pilot team size and they have a great support group around them.  So, that could still be a significant product.  And, I guess there isn’t a rule to say there couldn’t have been some preliminary work done by other Fog Creekers before the interns arrived.

(Side note: I think the Aardvark team kept a blog/diary going during that summer.  I don’t recall anything like that for this group.  Did I miss something?)

Second, unlike Co-Pilot this product is geared specifically for software developers.  So, that sets the space of the product within a relatively well defined market.  My expectation (guess) would be a new way to do something instead of a new thing that I didn’t know I needed (ala Co-Pilot or Twitter).

Third, the name is likely related to the function of the product.  Though, it could be a loose connotation.

That still leaves me with a lot of wild guesses…

First… I would love for Kiln to be the wiki product that was disbanded last year.  The FogBugz wiki feels like the red-headed-stepchild in the product.  We try to use it a lot, but it frustrates all of the users.  A great wiki that integrated with FogBugz would make my life a lot easier.

However, I’m not sure about the business model of offering a built in wiki and then a pay-extra wiki that actually works.  And it just doesn’t seem likely that they dropped the product last year and turned it over to an intern team this year.  A good Fog Creek wiki is what I want.  But I would be a little surprised if Kiln is it.

Second… Revision Control has always felt like something that Fog Creek could do and integrating with different Revision Control systems is a constant topic with FogBugz.  And…  Distributed Revision Control systems are all the rage right now.  And…  I could see the name Kiln working for a revision control system.  And…  if you were going to list the basic elements of good software development wouldn’t your list look a lot like: documentation, revision control and defect tracking?

Okay, that may not be your top 3 but surely those are in your top 10?

I’m not sure Fog Creek wants in the Revision Control business, but I could easily be convinced that Fog Creek believes they could create a simple RCS tool that “just works.”

Third… I happen to be a big fan of Yammer and communication is such a challenge for some teams.

Unfortunately, a Yammer’ish tool for developers doesn’t really sound like Fog Creek to me.

Fourth… Fog Creek has made use of User Voice for Co-Pilot and for the FogBugz Plug-ins community.  And lots of users have asked for tools for voting case ideas etc.  So, I guess it could be some sort of community voting system.  But why re-invent that wheel as a separate product?  Doesn’t seem likely.

Fifth… Another common developer’ish task is automated testing.  But that seems too platform specific for Fog Creek.  However, Kiln seems like a great name for a testing product.

We could go down the Joel Test for more ideas… Hallway Usability Testing?   Automated Builds?  Those don’t smell like Fog Creek products to me.

What else???

What do you think Kiln is going to be?  We should know pretty soon.

I think it would be interesting to see how folks are using the Backlog plugin which Daniel does not appear to use.

Any other Scrum stories out there with FogBugz 7?

If you have not yet heard about all of the new features available in FogBugz 7, there are several good articles from official sources.  The official FogBugz blog has the release announcement and a detailed look at EBS 2.0.  Meanwhile, Joel provides an interesting look at the vision statement that drove the last year of development at Fog Creek.

For the FogBugz user and fan, there are really some great features here.  Tags and Sub-cases have already dramatically changed my daily usage more than I anticipated.  My team will soon be reviewing our standard operating procedures to see what adjustments we may want to make to better utilize the new functionality.

Meanwhile, I saw these challenging tweets from a Jira kool-aid drinker:

Am reading the FogBugz 7 feature highlights. Srsly? People have been buying it WITHOUT that stuff for HOW long? Jira rocks.

http://twitter.com/discredittech/statuses/2777147868

Major FogBugs 7 features in Jira for years: SubCases, Tags, Plugins, Custom Workflow, Custom Fields

http://twitter.com/discredittech/status/2795616357

Before I get too far down this rabbit hole, I would like to re-iterate an early point on this blog and also make some qualifications.  First, I am in no way associated with Fog Creek Software.  I’m a user who drinks the Fog Creek kool-aid.  I drink the ‘Creek.

Second, I’m not very experienced with Jira.  Most of what I know about the product comes from their promotional material and some recommendations I’ve read in some Agile sites.  For example, I “know” that Jira is very Scrum friendly and is feature rich.

Third, I don’t mean any disrespect to @discredittech nor do I know anything more about @discredittech other than a few of his recent tweets I’ve reviewed and his charming bio in twitter:

A Dissatisfied IT Contractor working for a major IBank. My job sucks.

Fourth, I’m guessing @discredittech doesn’t know much more, if any more, about FogBugz than I know about Jira.

Now, with all of those qualifications in place I have this to say about the comments…

I don’t think FogBugz is now or ever has been in a feature race with the competition.

In other words, while the new features of FogBugz 7 are pretty wiz-bang great and even though some of them are long over due, the great thing about FogBugz is that it isn’t about the features.

The latest FogBugz web page puts it this way:

FogBugz makes it simple to track your projects. It focuses your team on what needs to be done, and brings schedules back into reality.

I believe the term Joel has used in the past is “drop dead simple.”  It is a Fog Creek staple.  It is an anti-feature.  And it is why I drink the ‘Creek.

And that is why I’ve been simultaneously eagerly awaiting this release and dreading it at the same time.  You see, it has been obvious for a while that FogBugz 7 was going to be a significant change from the past versions.  Flexibility was the keyword being tossed around in the forums and the occasional teaser blog post.  And that is not a word that has been used much in the past to describe FogBugz.

FogBugz has a steady history of simplicity built upon the assumption that the fewer decisions you force a user to make the more likely they are to actually use the tool.  What good is a defect tracking tool if most users won’t take the time to enter bugs?  What good is a project management tool if nobody will keep it up to date?  What good is a documentation repository if nobody will take the time to write and submit documentation?

My own experience with FogBugz is a testament to that mindset.  For example, a few years ago I finally convinced the right people that we needed to hire a Quality Assurance Manager.  It was the first official full-time QA employee we had ever had.  She walked in with roughly 20 years of experience in the industry but had never worked in a FogBugz shop.

As she learned about our software and processes, she was continually stunned by what she found.  Programmers that actually used their defect tracking tool.  Programmers that welcomed QA.  Programmers that valued traceability.

I credit that to two factors: brilliant employees (of course) and FogBugz.

And so this new flexible FogBugz 7 had me a little worried.  I wanted all of these features.  @Discredittech is right about that.  Some of these features should have already been added.  But I feared what it might do to the product.

I should not have been worried.  The Fog Creek team delivered the features without ruining the product.  And the resulting release  is a significant milestone in this product’s evolution.

What is the significance of FogBugz 7?  It is huge.  H-U-G-E

Was the identity of the product lost?  Absolutely not.  And yet, the product will never be the same again.  Pardon the hyperbole but…

FogBugz 7 is the Fog Creek equivalent of Bob Dylan going electric.  (Work with me here.)  With Bringing It All Back Home Dylan turned a corner in his career and yet he remained distinctly Dylan.  He was at the same time turning his old acoustic roots on their head while (arguably) maintaining his artistic credibility and extending his influence.

Note: I considered making a more timely music reference. I’m sure there is a Radiohead or Pearl Jam example out there somewhere but even those seem dated.  So, work with my Dylan analogy please.

Back in our little software world…  FogBugz 7 manages to pull off some very un-Joel like things such as custom fields, time sheet reports and custom work flows.  And yet it does so while staying true to the Fog Creek way.  Because, plug-ins or not, FogBugz 7 just works and the new features don’t get in your way.

One of the great things you can say about FogBugz 7 is that you could upgrade any FogBugz 3 or FogBugz 4 installation with version 7 during lunch and the team could continue using the tool the rest of the day without missing a beat.  I don’t think you would have to do one minute of training.  (We didn’t.)

Of course, a few weeks or months later, I would expect the team’s usage of FogBugz to change.  FogBugz 7 is just begging for you to update your procedures to become a more effective team.

So, yeah, Jira has had most of these features and more for some time.  Heck, their “Learn More” page starts with the heading “Features, Features, Features.”

And there is something too that. But don’t underestimate the beauty of “FogBugz makes it simple…“

So, take a drink from the ‘Creek.   FogBugz 7 is all new and as simple to use as ever.

Daniel Root has provided one of (maybe the first) review of FogBugz 7.  If you were not involved with the beta, then this is a good place to go to see what FogBugz 7 has for you.

Daniel Root’s FogBugz 7 Review

As more reviews roll in, I will try to keep a list going here.

I’m in the middle of my own software release in the coming days, so I’m not going to tackle a full review just yet.  But I will provide a mini review of FogBugz 7: I underestimated how useful the sub-cases and tags features would be.

FogBugz 7 appears to be well into the beta process.  Beta users aren’t supposed to say much (anything) about their experience until the product is released, so the Internet buzz on the beta is… low.

Just judging from Twitter traffic, lots of folks have requested and received access to the beta.  Meanwhile, Joel has announced that he will use Stack Overflow Developer Days as a vehicle for product launch.

Combine those two facts and you can reasonably expect FogBugz 7 to be generally available by October.   I would guess sooner than that but lets just say October and be pleasantly surprised if it is sooner.

I don’t think you will get an official word on that date from Fog Creek though.  They will tell us when they are ready.

I had planned to write-up a couple of FogBugz 101 style articles, but with all of the pending changes with FogBugz 7, it seemed a little pre-mature for that type of material.  But if there is a topic you would like to see explored, please drop a comment and let me know.

Things are slow right now, but there should be a lot to talk about over the second half of this year.  Even the official FogBugz blog has been pretty quiet recently.

But then I had this thought, what if Google Wave was embedded in the FogBugz case editor?

If you are not familiar with Google Wave, well, I suggest you set aside a few hours of your life and Google it.  But in a nutshell, at least as far as I understand the nutshell, Google Wave is flexible real-time collaboration and communication tool.  One might say it is an unholy combination of IM, Email, Wiki, Blogs, Source Control and Twitter.

Like so many other modern web ideas, it is either brilliant or ridiculous and it will be a while before most of us can agree which of those descriptors is correct.

However, it occurs to me that Google Wave (can we call it GWave?) solves a lot of common FogBugz Case Editor issues.  Consider:

• All edits are preserved.
• All edits are attributed to the appropriate user/author.
• Rich text.
• You can email it.
• You can create a conversation thread.

I realize that FB 7 (beta) reportedly has a (optional?) rich text field for each case that can be used as a description area that can, I assume, be edited by any FB user.  What if this rich text field was replaced by or included a Google Wave?

The first issue that comes to mind is security.  There might be some security issues with emailing a wave that contains sensitive FB case info.  But perhaps Wave already has a solution for that.  

If you work for Fog Creek and you just spent 3 years re-writing much of the FB system, does this make you want to scream, does this excite you or is this a non-issue?  

And for the rest of us out there, and I know this is too early to really know, does Google Wave represent an improvement to FogBugz case management?

Note: For the moment I’m ignoring the obvious questions about Google Wave vs the FB Wiki.

How do you use FogBugz to account for the QA process on your team?

There are a handful of questions that I have faced at work and I suspect many of you have too.  This list is not exhaustive, but hopefully it provides enough context for discussion.  

Note 1: Obviously, your development methodology will have a significant impact on your answers.  I expect Agilist, for example, to have a unique approach.

Note 2: I will try to use “FogBugz” terminology for the most part.  So, by “release” I mean a release as defined by FogBugz.

• Does your FogBugz case list include distinct entries for QA?
• Do you use a distinct QA/hardening/stabilization release?
• Do you create a “master” Scheduled Item case for QA of a release?
• Do you create a Scheduled Item (QA) case for validating each Feature case?
• Do you create a Scheduled Item (QA) case for validating each Area of a release?
• Do you set estimates for your QA cases?
• If so, do you use EBS?
• Do you rely on the Resolved vs Closed status to distinguish between cases that have been QA’d and cases that have not been QA’d?
• If so, how do you handle regression testing later?
• Do you use a different product to manage the QA of a Release?

Thank you, in advance, for your help.  You don’t have to answer each (or any) of these questions.  I’m just looking for some insight into best practices for QA with FogBugz.