4 ms·

Here is a very popular Quora question that details alot of the reasons why software estimates are wrong: http://www.quora.com/Engineering-Management/Why-are-so

Here is a very popular Quora question that details alot of the reasons why software estimates are wrong: http://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe?srid=u8eL&share=1 http://www.quora.com/Engineering-Management/Why-are-software... When I look back on my career the patterns that lead to good development were: 1) small team sizes, I'm a big believer that if version 1 of your product is developed by more than 4 people, its in trouble:) Small, super focused, and highly talented teams make the best version 1 products in my opinion, probably related to why some start ups can be more agile. 2) Everyone on the team has domain experience, ie its not the first time a product has been written. This is slightly at odds with the "second system syndrome". At my current company, when we wrote our algo platform, each member had done this before so we knew from a data, networking, machine learning, and trader's perspective what we wanted to get done. There was very little flailing around trying to learn the domain( ie no learning what ml techniques to use, how to connect to exchanges via FIX, no learning what a pairs trade was, etc). 3) 1, and only 1 person in charge of the vision. This might be obvious but debates, even when they are well intended, seem to slow things down. Having one person dictate what the next version will have seems to make things much easier. This is especially obvious in my current field of finance. Its very easy to spot the products developed by engineers for traders, vs the products developed by traders for traders, The former have lots of features that no one wants but they look pretty and the later, look ugly but make money:) META NOTE TO ANYONE DEVELOPING A TRADING SYSTEM No one cares what it looks like. I'll say that again, no one cares what it looks like. The Bloomberg terminal is the ugliest thing on the planet and they mint money. Function over fashion, always. I'd go as far as to state that a small team developing a trading system having a designer is viewed in the same light as a small team having an mba. That person might add value, but you'll need to justify why you're there instead of another engineer. I think alot of not shipping can be tied to these three things, too large of a team, not knowing what the final product will be doing and hence alot of experimentation and wrong turns and competing visions, or a lack of vision of what you are building.

tieTYT 12y ago
I ask this without having my own opinion on the matter: Won't those debates improve the design of the architecture? It's hard to imagine the time loss of debates being greater than the time loss of a rearchitecture.
- cyorir 12y ago
  I think that while having heated discussions on redesign/changing a specification can be important, it is better to try and wrap up these discussions before you move into actually implementing your project. If you have too many debates while actually working on the architecture (IMO too many of these debates take place at this phase, rather than ahead of time), then the engineers work on implementing one feature only to be told they must abandon it and start implementing another feature, etc. Consistency can be a good tool for keeping projects running on time without growing costs, even if the overall design is not as optimal as it could be.
- nostrademons 12y ago
  They do improve the design of the architecture, but the question is "Will they improve the design of the architecture more than shipping the product, letting it contact reality, and learning from experience?" There's an opportunity cost - debates cost time, time delays shipping, and shipping is what enables customer feedback. In my experience, customer feedback and actual experience is much more important for improving the design of the architecture than debating with other people. You can try to make your design slightly less wrong by consulting with other team members who are equally as uninformed as you, or you can get it right by going out and getting hard data.
  - kromodor 12y ago
    Unfortunately there is a psychological barrier that people must pass before having the understanding of their lack of experience and the need to face reality. Only informing them about this, in some cases, is not enough. It would really be well if people realized their bias, but they rarely do.
    - 12y ago
jonalmeida 12y ago
3 - Seems like the kicker for new co-founders that start up thinking, "We share the dream so, we'll coordinate together."

tieTYT 12y ago

I ask this without having my own opinion on the matter: Won't those debates improve the design of the architecture? It's hard to imagine the time loss of debates being greater than the time loss of a rearchitecture.

cyorir 12y ago
I think that while having heated discussions on redesign/changing a specification can be important, it is better to try and wrap up these discussions before you move into actually implementing your project. If you have too many debates while actually working on the architecture (IMO too many of these debates take place at this phase, rather than ahead of time), then the engineers work on implementing one feature only to be told they must abandon it and start implementing another feature, etc. Consistency can be a good tool for keeping projects running on time without growing costs, even if the overall design is not as optimal as it could be.
nostrademons 12y ago
They do improve the design of the architecture, but the question is "Will they improve the design of the architecture more than shipping the product, letting it contact reality, and learning from experience?" There's an opportunity cost - debates cost time, time delays shipping, and shipping is what enables customer feedback. In my experience, customer feedback and actual experience is much more important for improving the design of the architecture than debating with other people. You can try to make your design slightly less wrong by consulting with other team members who are equally as uninformed as you, or you can get it right by going out and getting hard data.
- kromodor 12y ago
  Unfortunately there is a psychological barrier that people must pass before having the understanding of their lack of experience and the need to face reality. Only informing them about this, in some cases, is not enough. It would really be well if people realized their bias, but they rarely do.
  - 12y ago

jonalmeida 12y ago

3 - Seems like the kicker for new co-founders that start up thinking, "We share the dream so, we'll coordinate together."