| Ok, so if you’re the only one thinking it’s a problem, and assuming they’re not simultaneously and uniquely non-rational, there may be some logic to this. Questions: - is the code / models / software expected to last a long time? Are these prototypes by another name? — will you actually have to pay for that tech debt one day? Are you paying for it now? Or Are there strong business winds that might require a total change or shift regardless of code quality? - are the products / hacks / software components strongly coupled? Are there strong dependencies between each team members output, causing you to be blocked on un hacking the hacks? - how much technical communication is expected to be person to person, ad hoc? is there an expectation that when you need to use or work with someone’s component, you should promptly sync with them? I say this as someone who 1) loves code quality
2) has worked in testing tools dev
3) has also worked on early stage teams. And sometimes, when you’re early stage, the highest value you can deliver is understanding what you’re actually trying to build. Hence, lots of Prototypes, experiments, measured hacks, differing conventions, etc. Now, all my prototyping days I’d say code quality was high (devs cared). But while tests and docs were super impressive, often they weren’t that impactful. |