Comment by solutionyogi | Hacker News Reader

Comment by solutionyogi | Hacker News Reader

Having mainly done line of business applications my entire life, I have a slightly different take.

Jira won because it was not opinionated. You can use it however you want. FogBugz had the philosophy to make bug entry super easy above anything else. Jira will let a manager define new custom fields and make them all compulsory. It perfectly fits how manager at big companies think.

FogBugz provides Completion Date Probability Distribution chart and Burn Down Chart [2]. Anyone who has worked for big companies knows that these two are USELESS for them. They set a project delivery date and you just have to hit it.

At my current company, we are going for SOC1 compliance. This forces an amazingly complicated issue workflow and they implemented it very easily in Jira. I am looking at FogBugz documentation on workflows [1], and I don't see how we could have implemented the same in FogBugz.

I also feel that Jira has a better ecosystem for plugins and integrations then FogBugz.

[1] http://help.fogcreek.com/7483/statuses-categories-and-workfl...

[2] http://www.fogcreek.com/fogbugz/features/project-management/

They set a project delivery date and you just have to hit it.

Do you find that this really works out, in practice? Joel has argued[1] that the only schedule worth anything is the one set by the developers themselves. Management can set relative priorities (X is twice as important as Y), but trying to force a faster deadline on the developers is like trying to make your Linux box run faster by renice-ing every process to -20.

Now, the problem with developer-set schedules is that they tend to underestimate how long things will take. Hence, FogBugz figures out how much each developer underestimates on average, and builds bell curves for the realistic completion time.

[1] http://www.joelonsoftware.com/items/2007/10/26.html

Do you find that this really works out, in practice?

No. Good luck persuading the management to try something else!

There may be a niche for enlightened managers or startup funders to promote such a thinking. If successful it will lead to a clear competitive advantage.

This is true. But there is no competitive advantage in going and broadcasting to all your competitors exactly how you achieved the advantage. So the development shops that succeed using this will keep it tight.

Rob Thomsett had an article titled "Estimation Games" published in American Programmer, 1996:

> It is our belief that over the 30 plus years of commercial computing has developed a series of sophisticated political games that have become a replacement for estimation as a formal process.

> More importantly, like all good games they are passed on from generation to generation by "children" I.T. people learning from "adult" managers who of course learnt the games from their adults when they were children and so on. Of course, none of the academic institutions [our preschools] prepare the new I.T. graduate for these games but rather, leave it to the cold reality of the work environment to teach graduates [the new children] that estimation techniques are only good for teaching in university.

> The good news is that I.T. can estimate better. The bad news is that there are lifetimes of games and refining of games that have to be avoided to do this.

There used to be a good copy of it easily visible on the web, today the best I can find for you is this PDF copy of the article: http://research.cs.queensu.ca/~ahmed/home/teaching/CISC322/F...

Previous HN discussion (~200 days ago): https://news.ycombinator.com/item?id=9182814

Also worth a read for a chuckle: http://www.dadhacker.com/blog/?p=2267

Managers are the ones that buy this stuff, not developers.

absolutely in enterprise SaaS.

beginning with Salesforce.com downwards you have vendors releasing on a fixed schedule.

your valve is scope, but even that is fairly fixed as customers drive what needs to get released when (not "stupid" managers).

Frankly the valve is often quality. Quite often something ships on a date. That something is usually crap.

In order to get schedule to change, you'd have to convince salespeople to do something. They are generally the ones doing the convincing.

In order to get the features to change, you'd have to get a product manager to give up what they want to build "because of technical reasons". That doesn't happen often.

But if the product ships with the new features on the agreed upon date, the only people hurt are the developers and the customers. Most people in the business who pretend to care about the customer experience are perfectly happy to do this because it gives them a big club to wield over the engineering team in future iterations.

A classic "pick two" situation: Fixed Ship Date, Fixed Scope, Fixed Quality.

More like "pick one".

>> They set a project delivery date and you just have to hit it.

> Do you find that this really works out, in practice?

Of course it works. You just redefine the project (or parts of the project) as you go, shrinking (or occasionally growing) the scope.

There's nothing wrong with a fixed delivery date, provided you can adjust scope and/or resources (to some extent) to compensate.

That is not my understanding of what most large companies do. Over and over I talk to people who have to deal with fixed dates and fixed scopes. The common outcomes seem to be:

1. Wait until the date is close. Redefine scope in a panic so that success can be declared.

2. Wait until the date has arrived or is past. Have rounds of tears and/or shouting; pick a new date and scope, often as illusory as the first.

3. When the date arrives, ship whatever terrible garbage you happen to have and declare victory. Spend the next N months "fixing bugs", which mostly means "finishing half finished features".

I've been in all these situations.

The key is to over communicate. When I'm managing a project like that in a situation like that I send an email similar to this:

As it currently stands our team will not make the deadline. In order to meet our priorities, I would like to redefine "feature A" to exclude "component Z". This means we will have to do manual work around X. The following alternatives are available: (A) change the deadline, (B) move feature A to next release, (C) remove some other feature". In the absence of any other guidance I'll direct the team to follow the plan above. Happy to discuss further.

I've always found this is a pretty effective strategy. Big companies aren't often dumb, you just need to know how to operate in them.

I think it depends on the company. I've worked inside organizations where that be entirely unacceptable. The date and feature sets are both fixed in advance and are treated as immutable. Nobody would say what you said, but if they did, they'd be on their way out.

Was it the organization or a specific manager who responded that way?

Both. The times I have seen it, it has been an endemic cultural problem, but most managers participate fully in the madness.

Indeed, there are many wrong ways to go about doing things. That doesn't mean there aren't also correct ways, and companies who do them that way. In many cases, big projects at large companies require a date. This is how you accomplish that goal.

Here we get to what I think of as the heart of the problem. Projects don't require dates. High-status humans in control-oriented systems sometimes choose to require dates as a means of feeling in control.

The outcomes I describe above aren't some strange, rare occurrence. They are the normal outcome for projects formed around arbitrary scope/date choices. But people keep doing it. Indeed, they often can't even conceive of alternatives. Why is why, as here, people speak of the choice as an intrinsic property of the project rather than a consciously made decision among a variety of approaches.

This isn't a human universal, by the way. All of this is an outgrowth of western 20th century business culture and management techniques. But it is so much the dominant culture now that alternatives are literally unthinkable for a lot of people.

Here's the issue, though - no matter how violently we may agree on the downsides of traditional project management, opinionated tools are just ahead of their time. The market is not at all ready to agree on what software workflow should look like. It just takes time for good techniques to propagate - this is such a young industry...

So until there is stable consensus among everyone up to even late adopters about how software work should be managed, any opinion built into the tool will end up being an obstacle for users who are still yet to learn agility the hard way.

The real value of an opinionated tool is the opinion itself. And that is something that has to be instilled first. Build a knowledge-base, a following, a community, then make the tool a companion piece.

Kinda depends on if it's more important to be on time vs complete. Sometimes hitting a window of time is more important than getting the feature done perfectly, like for an industry event that could build buzz, or a specific holiday season where being late means a lot of lost sales. The worst deadlines are fixed ones for no point, though.

> Do you find that this really works out, in practice?

We often worked for clients that had media advertising booked and paid for. The product had to be ready.

So you make it work. Reduce scope, phase the releases, whatever it takes.

I don't see how we could have implemented the same in FogBugz.

How would you implement the compliance without technology in place? I'm being serious, how do you think compliance happened in the days of 486s, TRS-80s, punchcards or no computers at all?

There isn't always a technical solution to a social problem, and JIRA's customizations are a micromanagers dreams. I'm sure there are good cases where that level of control is needed (your compliance case) but generally you don't need it.

Reminds me of the time we cleaned out a back storage room at an old job, and there were binders full of mainframe PL/I source code from the early 80's that had gone through paper code reviews, with the reviewers signature on every page.

I was at a job where we did that in the early 2000s.

I am not suggesting that you don't need technology.

I am suggesting that FogBugz doesn't offer enough flexibility in their workflow definition to do the gymnastics required for SOC1 compliance. FogBugz is trying to follow best software development practices and as you noted, Jira is a dream-tool for a micro-manager.

While I don't have any real data, for a good look at how it was done before things like Jira and FogBugz, I'd first look at IBM and the military. IBM used to do a lot of consulting for both documentation and process compliance though I don't know much of the details (mostly heard stories from my uncle who works for them). The military did it largely with strict discipline and documenting everything in triplicate if the media is any indication and even then they likely weren't perfect.

The technology layers enable a strict uncaring rule keeper to do the job at all times and enforce things even if they might not apply, it makes the task simpler but it's still some of the same idea, a single bottleneck exists to ensure compliance for something and it gets well documented.

They used to say the Space Shuttle isn't ready to fly unless the weight of the paperwork is equal to the weight of the shuttle.

My first job was writing JCL decks on an IBM ESA/390. We had several shelves of manuals for the thing. And people read them.

I will agree that "intelligent" time tracking features in FogBuz ~4 years ago seemed relatively flaky and random.

JIRA's benefits are likely in customization - which is a giant pain for managers in some ways, but it's nice that it can do it, but JIRA is supremely frustrating when editing dashboards. Every time somebody changed a component name, it would break all the underlying queries, etc.

I think there's a huge market for someone to overtake JIRA because it's so unfriendly, and I was very happy for various projects that had a team scope small enough to use Trello, but with better searching and a few more (optional) controls on top or something.

Since there's common DNA there, I think Trello could evolve to be that. I hope it can.

(BTW, I'm also nostalgic a tiny tiny amount for the end-user usability of Trac.)

All bug trackers are literally crap. It's a really hard tool to write. The ones that make dealing with individual items/cases/tickets like Trello fall apart when you are dealing with hundred's of items. The ones that manage groups of items together efficiently (jira, maybe fogbugz) are a pain to do data entry in.

Try TargetProcess ... Gets very little attention. But hits that sweet spot for me at least.

And then there are those which seem to manage collections and data entry but fall down completely when it comes to dashboards and data presentation. (see youtrack).

Not supporting custom fields was a deliberate decision: http://www.joelonsoftware.com/news/20020912.html

"But the dilemma for us is that many customers are evaluating bug tracking software and they consider the lack of custom fields to be a major weakness in our product.... But it's still rude of me to tell customers that we don't have that feature for their own good, even though it usually is, and we're losing some sales because of it."

Reply on news.ycombinator.com