Hacker News new | past | comments | ask | show | jobs | submit login

First of all, This platform is amazing. I love the feel, UI, and how I can easily try it out without signing up. It reeks of quality.

However, every platform in this market tries to solve a similar problem in a different way but I think no one tries to solve the biggest problem.

That problem is that there will be one or two people that really care about all of this tracking stuff but everyone else just don't. Developers don't need to check tracking tools everyday to know what they need to do and once they finish, they will not update the tracker. So when the people that cares check the tracker, it doesn't give them the latest info.

So the problem with tracking software is that it requires everyone to use it the way it was meant to be used, but employees just wanna do the 8 hours and go home and not care who is on what page.




Thanks for the feedback! It's really great to hear appreciation like that.

This is an awesome point, and one which we're keenly aware of. This is how we think about this:

Constructor must serve different roles with their own notions of success, and those notions may be at odds. That is, there are some tensions and tradeoffs within teams that exist independently of any tool, e.g., managers want stuff reported but developers just want to build software and not fill out TPS reports.

So our approach to solving your biggest problem is to try to create the best UX for each role, period, which implies Constructor must mediate these tensions where possible. For instance, our approach to blockers is very lightweight and we saw immediate uptake from devs when this was released, indicating they saw it as a help, not a burden. And of course it makes it apparent to managers what's going on without having to pester anyone. So we consider this a feature that helped both managers and devs do their jobs better without imposing an unwelcome burden on anyone. We're looking to extend this pattern in much more clever ways to get managers the facts they need without burdening developers with housekeeping tasks to provide those facts. It's a tough problem but we're optimistic we can make headway here.

Thanks for raising this point; it's really, really important.


That’s a good point. It makes me think that what one can do is to add a library in code that logs that the issue hasn’t been resolved.

Like `if (inputsNotHandled) _sendToJira(“issue is not resolved”)`

But that’s probably not easy to do in most cases…




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: