3 ms·

That’s a fair and reasonable perspective. I’m curious if you’ve worked on such a product that had a baked-in level of maturity from the start? I never have. I’d

That’s a fair and reasonable perspective. I’m curious if you’ve worked on such a product that had a baked-in level of maturity from the start? I never have. I’d be much more inclined to agree with you if I had encountered a v1 product that wasn’t a total clusterfuck! Scalability engineer and compliance engineer very much are phony mumbo jumbo from the perspective of a software engineer. However from the business perspective they are very real and I think they are helpful to communicate one’s own level of maturity and ability for the business owners to trust you to get things done for them. It’s about communication and signaling more than the reality of what you do.

cjfd 7y ago
I have seen the startup stages of software projects with varying levels of quality. The whole spectrum from very bad to very good can be observed and/or participated in in the wild. The good ones start out with one experienced developer. After two or three features have been added (within two weeks to a month) more developers, possibly less experienced ones can be added. Their number should grow somewhat slowly mainly to make sure that they are not getting in each others way too much. Practices that make this work are automated testing and code review. Occasionally, some pair programming can be practiced, especially when some refactoring is needed. I am talking about limited refactoring here, maybe taking two to three days. If the project can be split in a front end and a back end one may start out with two developers. In theory a system that consists of N services might start with N developers but if N starts out larger than 3 one is quite likely engaging in over engineering.
PaulStatezny 7y ago
I agree with cjfd; it's a false dichotomy. "Either we put zero effort into making this code maintainable, or we won't move fast enough." > I’d be much more inclined to agree with you if I had encountered a v1 product that wasn’t a total clusterfuck! I'm personally working on a v1, and (you'll have to take my word for it) it is far from that. We are making conscious decisions: "here's a guess about the future that we're confident about, so we're willing to add in more structure/abstraction here," or, "We're not sure about the future of this feature set; let's be clean but minimal about it." Also, co-workers have raved about our work on this project, including speed. So that's further evidence that it's a false dichotomy.

cjfd 7y ago

I have seen the startup stages of software projects with varying levels of quality. The whole spectrum from very bad to very good can be observed and/or participated in in the wild. The good ones start out with one experienced developer. After two or three features have been added (within two weeks to a month) more developers, possibly less experienced ones can be added. Their number should grow somewhat slowly mainly to make sure that they are not getting in each others way too much. Practices that make this work are automated testing and code review. Occasionally, some pair programming can be practiced, especially when some refactoring is needed. I am talking about limited refactoring here, maybe taking two to three days. If the project can be split in a front end and a back end one may start out with two developers. In theory a system that consists of N services might start with N developers but if N starts out larger than 3 one is quite likely engaging in over engineering.

PaulStatezny 7y ago

I agree with cjfd; it's a false dichotomy. "Either we put zero effort into making this code maintainable, or we won't move fast enough." > I’d be much more inclined to agree with you if I had encountered a v1 product that wasn’t a total clusterfuck! I'm personally working on a v1, and (you'll have to take my word for it) it is far from that. We are making conscious decisions: "here's a guess about the future that we're confident about, so we're willing to add in more structure/abstraction here," or, "We're not sure about the future of this feature set; let's be clean but minimal about it." Also, co-workers have raved about our work on this project, including speed. So that's further evidence that it's a false dichotomy.