Hey, Disclosure: In the past I worked for ENTP (the makers of Tender and Lighthouse) but the opinions I express here are my own.
comments inline: On Fri, Jul 23, 2010 at 8:03 AM, satsumac_sw <[email protected]>wrote: > > > Why should this not be possible to do combined? > It depends how similar you think customer support is to bug tracking. To me, bug tracking has a lot of ceremony surrounding milestones, priorities, statuses etc. On the other hand customer support has very little ceremony: pretty much anything the customer wants to talk about is fair game and they don't really care that the thing they talked about has been reassigned from myself to a colleague. > > If I'm not mistaken the major difference you describe is the "visual" > separation of Tender being the public interface and Lighthouse the internal > private one. > It's not a visual separation - it's much more fundamental than that. Each product was designed starting at "what should it do?" moving towards "what data needs to be stored?". In the end, there may seem to be some duplication of "what data needs to be stored" but the similarities, especially in terms of business logic, are dwarfed by the differences. > However (from my understanding) this could easily be done with just one > database table and an additional "issue type" flag. > If for a given issue the flag's set to "bug report", then it shows up in > the internal bug tracking system. If however the flag happens to be set to > "feature request/user question", then it simply shows up in the public > interface. > If "what list does it belong to" is the *only* difference then sure! But I find it hard to believe that you could drive the *entire* difference in workflows based on a single (effectively boolean) flag. > And connecting two database entries (like when connecting between > Lighthouse and Tender) is fairly straight forward with a single database, > too (if not much simpler). > Also if a user posted a feature request which turned out to actually be a > bug, then it's just the switch of a single flag to turn it into its proper > issue type, while with separate systems it would probably require much more > (transfer and synchronization) work to do so. > > Well... it's now set to "bug report", only visible in the internal tracking system right? How do you get more information from the customer if it doesn't appear in the public interface? How do other customers see that the issue has been brought up? Where can they add their "+1 - this is really important to me too!" comments? It's already starting to look like there's more to it than just a single field to express "bug report" vs "feature request / user question" and that's just for "what list does it belong to". > The thing of having two distinctively different "views" (as as such also > probably different "controllers") for handling "bug reports" and "user > support" is kinda obvious, no doubt about that. Different "views" are _just_ > a matter of filters and visual representation, while the internal logic > wouldn't have to differ much at all. > > Like I said before, I think the ceremony of bug tracking is completely different from the ceremony of user support. Given that ceremony dictates the "internal logic", I've come to the opposite conclusion than you: the internal logic is completely different. > I'm wondering however why there appears to be a need (or tendency) for > separate "models" of (probably naïvely thinking) the same structure. > As from my understanding separate systems would result in a lot of code and > structure redundancy (of which most could be solved by shared codebases, but > not all!) and coding and maintenance overhead, there just has to be some > serious advantage, making it worth the effort, I think. > > In my experience, two highly-focused systems that talk to each other via a single, well-defined, integration point will *always* be simpler to maintain than one system that tries to do two different things. It's easier to get complex behaviour by assembling a bunch of simple things that work together than it is to make one thing that does it all. > One advantage of separate "issue tracker" products obviously is the chance > to bill your users twice, no doubt about that. But I can't believe this > being the only reason. > > It depends on where you're coming from. If you're a customer who wants both products, you may think you're being double-billed. If you only want one product, then you're only paying for the development effort on that product's features. Keeping the products distinct does mean that they can proceed independently and there's a lot less chance of stuff like "sorry guys, we can't implement this customer-support feature because we're still refactoring the 'one true table' to support a new bug-tracking feature". So obviously I'm asking more from an implementation standpoint than from the > opint o a user. But I thought user experiences might actually give some > insight on the benefits of each implementation, so I asked anyway ;) > Well, I hope this doesn't come across as really condescending, I believe that's where you're going wrong. The product is not the rows and columns, or the algorithms, or the views. The product is how you interact with it: what it asks of the user and what it gives back. To put it another way, the implementation should not be the 'no compromises' underpinning of a product, the user's expectations and objectives should be. Start from the users (developers and customers), define "what should it do?" and work towards "what data needs to be stored?". If your developers and customers share the exact same expectations and objectives, you'll end up with one product. The more their expectations and objectives differ, the more likely it is that you'll end up with two products. And with that I'll leave you with a quip once uttered by one of the authors of Tender and Lighthouse: "Users are just Comments with passwords". Taxonomy is hard :-) Regards, Trev > > --- In [email protected] <macsb%40yahoogroups.com>, Scott Morrison > <sm...@...> wrote: > > > > Hi Vincent > > > > I am using Lighthouse with Tender and I really like having the two > separate systems -- Tender as the discussions with the end user -- we can > use this to ascertain the problems -- many issues are not bugs but just > general support issues -- I have one person that whose job is basically to > work with the end user to figure out what the problem is and to communicate. > > > > And Lighthouse as the internal system for my coders to work with -- they > only get the issues that are actually bugs, we can easily keep track of bugs > in this system that we discover internally, set up work orders -- etc. > > > > The nice thing about Tender + Lighthouse is how they talk to one another > -- so that I can easily associate a specific bug with multiple user > discussions, and also break a user discussion into multiple bugs. It then > allows me to back track from resolution of a bug to beable to communicate to > multiple users having a problem. > > > > If it is one monolithic system, this isn't as easy to do. > > > > My 2 cents > > > -- -- Trevor Squires http://propaneapp.com [Non-text portions of this message have been removed] ------------------------------------ MacSB email guidelines: http://tinyurl.com/2g55d6 Use MacSB-Talk for off topic messages: http://groups.google.com/group/macsb-talk Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/macsb/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/macsb/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
