4 ms·
Don't just go into blaming culture. Everyone should accept that is just super expensive to do good software. Money help, but it is also expensive in terms of f
by ozim 3y ago
Don't just go into blaming culture.
Everyone should accept that is just super expensive to do good software. Money help, but it is also expensive in terms of focus and time. Having team of developers/business analysts/QA focused on one project is loads of money.
Even for small team like 5 devs, 1 QA, 1BA - let's say every team member gets roughly $6k a month that is like $42000 a month. Now question is how many features/fixes can you do with that team? Well form experience you get maybe 8 big features, where big feature is like 2 weeks of work for a developer back and forth from QA and getting clarifications from BA, you have 5 devs but in reality there will be no 100% alignment and you still have bug fixes, busy work etc.
So $42000 divided by 8 gives that any feature costs around $5250 to build initially and still might be having bugs and need for adjustments. But you have at any point in time at least 3 people looking at the feature and making it work/finished.
Now we can talk about culture where companies throw $5k at a feature on a whim, burn everyone's time with useless meetings on VC fueled life support compared to FOSS where budget for a feature is more like $1k of whatever spare time some dude somewhere has and he is "making the feature up, coding it and testing" in most projects on his own.
- a1o 3y ago> making the feature up This is super hard, often someone will write a mindless issue with a feature request without thinking about it profoundly. Than the dev has to sift through the text to understand what is the underlying problem the user is facing, if the proposed solution is actually a good solution to that problem (it often isn't), what is a solution considering long term maintenability, if the feature has synergy with future features or if it solves or is close to solve other already existing issue so the solution scope should be adjusted. The design stage is huge and it's hard to do alone and also hard when other contributors only raise edge cases to try to break a proposed design without validating if the problem the developer extracted is adequate. The scoping and design is often very time consuming and hard to get it right. Usually you end up designing to the scope of available time to solve the issue at hand - time being a rainy Sunday afternoon, or around three and half hours.
- bombcar 3y agoWhich is why you can be entirely helpful in an open source project even without knowing how to code. If you can learn the general program, and interface with the users as a liaison between the developers and the bug tracker, it can be quite valuable.
- mortenjorck 3y agoAs a product designer, I naturally agree with this, but... are there any instances of this actually happening? I suppose there's Blender, but it's kind of a special case.
- MichaelZuo 3y agoAlso there's the possibility to help in writing documentation.
- ajb 3y agoThe question there is why you're operating using teams of 5 devs. The most productive environments I've worked at were ones where single devs had ownership over a chunk large enough not to require that much interaction (IE an amount of interaction that you would contemplate between teams, not between devs on a team) The issue with that is that you have to eat a big handover cost when people leave. But these environments had great retention and long contractual notice periods, so it wasn't a huge issue. IMO the "two pizza team" isn't as productive as people think.
- throw_nbvc1234 3y agoHow did oncall/operations work?
- ajb 3y agoThe companies where I worked like this didn't run services, they shipped releases. Which is how open source stuff generally works, although the income part can be a service (but not always)
- palata 3y agoI am in a company where most of us are "experts" of one part of the system. This is very stressful (because when there is an emergency related to my part, I am the expert on whom management is waiting), annoying at times (because nobody cares about my part, they have their own stuff to do, so it's hard to share), painful at times (when I'm struggling, I don't really have colleagues who can help), and annoying again when someone is on holiday and we need a change in their part. Agreed on the handover cost, though (obviously). Not saying that 5 devs are required, but 1 is not always the nicest IMO.
- ajb 3y agoFair comment - I'm not saying it's a panacea. Just that it's productive.
- pixl97 3y agoHaving one person that knows everything about some system is great, until they get hit by a bus.