t3e

Cool concept! I'd like to list an app but I can't seem to scroll all the way down to the bottom of the terms.

Check out https://www.hello.coop/ – super early, but they're building this, with an unusual governance structure designed to keep control in the hands of users.

(I'm not affiliated with them.)

I posted this on a different topic recently and it's apropos again: I'm currently reading Tim Wu's "The Attention Merchants" about the history of advertising and can't recommend it enough. It's informative, thoughtful, and well-written, but not a happy or encouraging story, alas.

I'm currently reading Tim Wu's "The Attention Merchants" about the history of advertising and can't recommend it enough. It's not a happy or encouraging story, however.

Thanks for the tip!

We had the same problem in our 2016 Outback until the head unit died. The only thing we really miss about it is the backup camera; but we can live without that, and apparently the stereo, as a fair price for being free of bluetooth audio hell.

Constructor co-founder here – thanks for the shout-out, Peretus! Seeing customer feedback like this is a great way to start my day.

For anyone who doesn't know us, we have an unhealthy obsession with simplicity and set out to build something as conceptually simple as Trello but with much better usability, and specifically for software teams.

Shameless plug for Constructor[1], we're early (new website on the way) but have a bunch of happy customers, many of whom came from Jira, the rest mostly from Trello (to which we're most often and justifiably compared, we keep it simple!)

1. https://constructor.dev

There is no end to the search for a developer productivity metric, but it refuses to be found for reasons that are fairly obvious to technical people, but that doesn't stop people from trying – for decades. So now they've retreated to these vectors called "frameworks" that try to obscure with complexity the fact that they are not in any way able to "measure what matters" – in this case, the ratio of value output to value input – nor are in any way deserving of the term "metric". I contend that such non-measures are of absolutely no value to engineering managers; they're management theater and purely a distraction and a waste of time.

Let's leave aside for a moment that this piece begins with an impressively uninformed and circular definition – "Developer productivity, in general, refers to how productive a developer is during a specific time or based on any criteria." – and focus instead on the question of why does this stuff keep popping into existence; what's behind it?

As a tech exec who's researched and given several talks on this to large audiences of non-technical execs like CEOs and CFOs, I believe the root causes are an understandable and intense desire for "visibility" and exec accountability coupled with a set of false beliefs held by non-technical managers including "anything can be measured if you try hard enough" and "nothing can be managed unless it's measured" and the classic quantitative fallacy of "things that can be measured are more important than things that can't be". Besides, it's only fair that if the VPs of sales and marketing have to stand up and talk about funnel metrics and sales rep productivity (with real metrics like net new bookings divided by fully loaded sales rep cost) that the VP of engineering - an often enormous fraction of a SaaS company's budget – should be similarly held to account for some number, any number, we just need a number, so we can look for "trends" (actually, noise). It also seems to be driven by a push from HR for fairness in promotions and terminations, which is also totally understandable, yet misguided.

I have a wisecrack response to non-technical executives when discussing this which is "how do you measure your own productivity?" that helps them understand the absurdity of what they're trying to do and how common it is that no true measure of productivity exists. People really struggle to understand that some metrics, no matter how great it would be to have them, simply do not exist, and so we have this – measurement theater.

[edit: fixed typo]

Thanks for your feedback and questions! Constructor is a great choice for teams using Trello that are feeling the pain of its limitations but don't want to sacrifice its glorious simplicity, or teams using GitHub Issues for similar reasons, or non-dev tools like Notion or Asana looking for something that understands software dev but isn't extremely complex to configure and use. We've been building it for a little over a year now, having onboarded our first customers in Jan 2021 and raised our first round shortly thereafter.

Our differentiator is lightweight flexibility, supported by conceptual models that reflect reality and don't impose one particular way of doing things on teams. Our goal is for teams to be able to "start simple and evolve easily" because for many teams their process is always being adjusted as they grow and mature. Our approach is essentially "Trello is like 90% of what many teams need, let's redesign it from the ground up for software teams and get it to 100%". It's early days but it's an approach that seems to resonate with many teams. At least partly this is because PMs and designers readily understand Constructor instead of being annoyed/overwhelmed, so everyone is happy using the same tool, and that's pretty important (to avoid tool schisms).

It's a practical limitation; we don't have a mobile app (yet) nor is the web app mobile-optimized (yet), but you can certainly use it on your phone – and hurl abuse at us until we fix it.

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.

Thanks, Helin! Very happy to hear I've been helpful; I'll go ahead and add myself to our features comparison page.

We don't disagree and we've heard from non-technical managers and designers that Constructor has the potential to be simply "a better Trello for everyone". This is probably because despite being designed for software teams we try to serve all roles equally well, i.e. make sure we create an outstanding UX for the non-developers on those teams. Something we've seen happen at a lot of places is a "tool schism" where part of the team (design or PM) will cleave off and use Trello or Basecamp and leave the devs to Jira because they find it unusable, but the devs need their Jira for various good reasons. Constructor is designed to prevent tool schisms.

Your 80% observation is if anything an underestimate; there's almost nothing in Constructor that makes it dev-specific beyond the GitHub and devops integrations that are mostly absent if you don't activate them, and would be easy for us to make totally optional. This surprised us when we realized it, because we are quite devoted to serving software teams specifically.

Thanks for the feedback!

- List view is on the roadmap but not designed yet; we'd love to understand your needs in more detail if you'd be up for dropping us a line at research@constructor.dev.

- By prioritize I presume you mean set an absolute priority? Priority right now is explicit in the ordering of tickets within their respective columns, but it's relative, not absolute. We're open to adding absolute priorities.

- You can search tickets with the search in the navbar, or filter the board to show a subset of tickets with the filter box.

- We haven't embarked on i18n/L10n yet but it's just a matter of prioritization – what language(s) do you require?

Thank you for this thoughtful comment, I’m happy somebody challenged us on this controversial point of our philosophy.

I disagree that a tool being process neutral implies anything about how the process ends up being designed, e.g. “process by committee within each customers organisation”, other than it won’t be decided by the tool. Process neutrality removes a set of constraints that in our experience add a lot of friction when teams want to work differently (and makes designing a great UX harder because of combinatorics).

There are indisputably tons of teams that seek and benefit from process guidance, including the ones I’ve run, but we think that should come from mentors, books, blogs, etc. – not the tool.

I agree that a lot of issues in Jira stem from wretched implementations, but I lay the blame for those implementations squarely at the feet of Jira. If most of the programs written in a language were impenetrable and borderline non-functional, would you blame the users, or the language?

Our biggest beef with prescriptivism in tools is that it impedes exploration and evolution of process changes that we feel are important to teams adapting well to growth and changing circumstances. It’s a much harder proposition to build a flexible tool, but we feel it’s necessary for this reason.

Thank you for the feedback, and I completely understand and share this sentiment. We're very cautious when adding new features and are obsessed with keeping the out-of-the-box experience utterly simple and tuned to exactly what a small team needs. It's a major design consideration for us that as much as possible, complexity is opt-in.

Linear's a great step forward but too prescriptive and still too heavyweight for lots of teams. Our focus is on dramatically simplifying, and aligning the core conceptual models with how teams actually want to work, e.g. threaded comments, flexible blockers, user-defined work structures, etc.

Thanks! We have the exact same complaints, and that's why we invested so much effort in this approach. I think a lot of companies would never do this because they'd fear adversely impacting their conversions metric, but our goal is to just get people to understand our product as quickly and easily as possible and hopefully get feedback.

We also really don't like product tours that lock you into an endless sequence of modals, so we came up with this "overlay" that users can turn on and off, inspired by museum audio guides you can hold up to your ear whenever you like, or ignore entirely.

No list view yet, but it's on our roadmap!

Hi, thanks for your feedback and questions.

1. We have something in this direction already in the form of "guest users" that can be added to your boards and don't count as a seat. They currently have full privileges on the boards they can see, though – our permissions model isn't fine-grained yet.

2. Sounds like we may need to improve our description of this feature, but right now, we're optimizing for small-PR "trunk-based dev" [1] workflows where a ticket can have several PRs, but a PR always maps to a single ticket. We push the ticket info onto PRs in GitHub so code reviewers don't even have to click through to Constructor to get the context they need to do their review. We'll definitely support use cases like yours in the future, though!

1. https://trunkbaseddevelopment.com/

Thank you for the feedback!

Definitely!

Thank you, we see the error and are investigating.

Edit: fixed now, JWT token issue with Auth0.

Jira offers them much more in the way of process management, reporting, and integrations with the likes of ZenDesk for its complexity. They seem to think of GitHub as just for the coders and aren't comfortable there.

You can forage for those on the Oregon coast! I was just given some by a friend and they're tasty; had never had them before. But they do smell a bit like gym socks.

I talk to dev team leaders (EMs and PMs) multiple times a week about project management and it's quite rare that we find anyone using GitHub apart from very small teams (2-3 devs). Our research suggests product managers especially tend to prefer things like Notion/Trello and really don't like the complexity of GitHub.

Disclaimer: I'm a founder at Constructor (constructor.dev)

We're deliberating this ourselves. Our investors strongly advocate removing the "beta" because our product is solid and complete (in fact pretty polished at this point) and we're doing ourselves no favors. I think they're right. To me the question is simply: what's more accurate? We were honestly in beta 8 months ago; at some point we just had customers happily using a product we're progressively making better.

Hi, we’re Seth and Andrew (Aalk4308), co-founders of Constructor (https://constructor.dev), based in NYC. We’re building a tracking tool as lightweight as Trello for all the small dev teams out there with basic needs, and we’d love your feedback. You can try it out by clicking “Try the demo” on our website. You’ll get your own private, mutable workspace prepopulated with dummy data (no email or signup required).

We started building Constructor about a year ago after talking to lots of CTOs/VPEs and product leaders about their frustrations with this space and frequently hearing “Trello’s a great tool to start with, but we know in six months we’ll want something more tailored to software dev”. Some of them had in fact used Trello all the way to exit with teams of 30+, but they’re the minority.

Trello’s great in a bunch of ways: it’s quick to set up, there’s not much to figure out, and the whole team can use it, not just the developers. It also strongly biases teams away from process complexity. But since it isn’t purpose-built for software developers, it lacks a first-class GitHub integration, backlog management is painful, and discussions are onerous. This all adds up to wasted time. But for many teams this is still preferable to heavier-weight alternatives.

So we built Constructor for small dev teams with basic needs who just need to get up and running with a tool that stays out of their way – but also understands how software is built. We aim to retain what’s great about Trello while redesigning it from the ground up for software dev teams.

We’ve been in private beta since January with teams ranging from two to more than 10 people. There’s clearly a lot left for us to improve here, but we wanted to share what we’ve built and get feedback from a broader audience.

We realize there are lots of tools in this space besides Jira and Trello, including several new ones in the last year or two, and we don’t expect ours to be right for every team. But we think it will help small teams keep their process light as it evolves, and save them time and frustration.

Thanks!

P.S. There’s a dark mode not yet exposed in the settings; if you want to see it just change the body tag class from c9r-light-mode to c9r-dark-mode and optionally add the class c9r-dark-high-contrast.

This aligns with my experience talking to lots of small startups of this size. It amazes me that 2-man shops use Jira, but they do, because they know it from their previous jobs and don't want to bother finding/learning a new thing. We also run across Trello and Asana a lot.