4 ms·
The thing to understand is that software is not useful in and of itself, it is only useful for automating or increasing the efficiency of some other endeavor.
by tacostakohashi 4y ago
The thing to understand is that software is not useful in and of itself, it is only useful for automating or increasing the efficiency of some other endeavor.
If you imagine, say, a hotel, it has plumbing that makes the toilets flush, and an accounting department that pays the bills and stuff, but none of those are an important driver of how people choose their hotels. Upgrading the plumbing will not lead to more guests, but if the plumbing breaks, that can lead to a negative experience and needs to be fixed quickly by a competent plumber.
It's the same with software - you need to figure out what the actual end goal is (more sales? attract a new client? more reliability?), and then the productivity of the developers measures how their software changes contribute to that outcome.
- ludovicianul 4y agoThat's true. But in the same time I think it will be useful to _understand_ if I can deliver that vision with 10 people or with 100 people. You can start with the assumption that everyone has good intentions and will contribute similarly (in correlation with their experience and capabilities), but I think it's missing the bit that will tell you more objectively if that's the case.
- skydhash 4y agoYou can even deliver with a single person. But that leads to more time spent on building. Adding more people adds more time spent on communication. There is a sweet point somewhere, but there's no formula to find it, as many factors depend on the human side of the software developers.
- tacostakohashi 4y agoSounds like a read of The Mythical Man-Month is in order? Even with the assumption that intentions are good and contributions are equal, that is not to say that the task of software development scales linearly as more people are added.