i enjoyed the article. i refuse to answer publicly whether i am working on a bullshit software project or not. i believe in addition to bullshit software proje

i enjoyed the article. i refuse to answer publicly whether i am working on a bullshit software project or not. i believe in addition to bullshit software projects, there exist projects where the business case is good, but the implementation is very dysfunctional and has poor communication, bad or non-existent coding standards, code architecture and team boundaries that don't make sense, etc. you do talk briefly about this in the quote > That job also taught me that tech and the business case for a business case are mostly independent. You can have a strong business case and be successful with garbage tech, and the reverse is also true. You should prefer a strong business case because customers are so important. but i think it is perhaps worthy of it's own article. what to do when your company has thrown so many developers on a project that should have one? what to do when your "design" (term used extremely liberally) has no conceptual integrity? i wish i knew what fred brooks would do.