6 ms·

Probably an essential mistake is to put multiple people to work on a greenfield project at once, when the requirements are particularly uncertain. Better to al

by vemv 10y ago

Probably an essential mistake is to put multiple people to work on a greenfield project at once, when the requirements are particularly uncertain. Better to allocate a single full-stack dev to experiment for a couple weeks. He also will interact with the business owner daily. Let him focus on the business logic and also the core user interactions. On top of that MVP foundation (i.e. on week 3), you can put the rest of the team to refine backend, frontend, graphic design and so on.

ninkendo 10y ago
> Probably an essential mistake is to put multiple people to work on a greenfield project at once, when the requirements are particularly uncertain. This statement rings so true to me that I really hope there exists a fleshed out version of this theory, with examples to prove it and maybe a catchy name, etc. Where I am now, I've literally participated in an identical thing being built in two ways at two different times: - The first time, I was the initial full-stack dev, along with one other guy (we were more of a duo... we paired a lot and worked pretty fluidly, it was kind of a 2-person equivalent of a single-person experiment.) The result was finished in 3 weeks and was flimsy but cohesive. Eventually the team was reduced to just me and I carried out the project for a few more months before a proper "team" was on board. - Then, the company noticed what we had done, decided that a bunch of other people had done similar things (it's a large company, after all), and then a 250-person organization was formed to write an MVP that was largely identical in scope. I wasn't in any leadership position in this new org, so nobody really cared that I had experience in this. I was reduced to writing a tiny insignificant part of the larger whole while our director drove the requirements. We're 10 months in and haven't shipped the first milestone yet. In the first example, we were almost too successful. The resulting product was used by thousands of people, for important things, with a lot of satisfaction and kudos from the users. But the total size of the team never really exceeded 5-10 people, so it got to the point where we were burned out supporting it, and there weren't enough reserves to call in to help because of the "second system" distracting everyone: In the second case, we don't have our first customer yet (although we've only kind of "soft" launched.) We did a massively half-assed attempt at agile that was basically "waterfall, but more vague, and please work harder", where we kinda half-assed came up with requirements, split everything up into 10-15 major "tentpoles", each of which was developed by separate teams. 6 months later we decided to start "integrating" all of it. 4 months after that, things finally kinda sorta work end-to-end. I've gone through a ton of self doubt through the process. In the first case, it worked only because there was almost no communication: we just did what we felt like, explored, and we were lucky that the end result worked. "Clearly, this will never scale, and is no way to run a real software product", I remember thinking. When the org got huge and we did our second system, I thought "Finally, I can learn to do what real software devs do and work for a big team with communication and requirements, etc". And inevitably when the result is a big pile of shit, I can't shake the feeling "this would've been better if I knew how to do real software development and work with a large team." Self loathing ensues. So I witnessed the pendulum swing each way. The first way was massively successful, but I suspect isn't sustainable (the product is withering due to lack of support now.) The second isn't successful at all, and is a complete mess, but maybe it'll be better with time. The only thing I know for sure is that few companies in the world can afford the amount of wasted time and energy we've spent on the second system. I suspect the real world works more like the first case but I don't have enough experience to know. I can't shake the thoughts of "I haven't seen real software development yet", and I don't know how much validity there is behind those doubts.
- vemv 10y ago
  Wow, the numbers (headcount / users / allocated time) speak alone! Thanks for sharing.
- ebiester 10y ago
  > Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. > Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. http://agilemanifesto.org/principles.html http://agilemanifesto.org/principles.html It sounds like the system started off as agile and the second system lost the plot.
dasmoth 10y ago
Perfectly put. I've been trying to push this kind of thinking recently. Most successful big projects grow out of a successful small project.
- vemv 10y ago
  > Most successful big projects grow out of a successful small project. This is probably true, one could even say that forming a big team from day one is cargo-culting others' success.

by vemv 10y ago

ninkendo 10y ago

> Probably an essential mistake is to put multiple people to work on a greenfield project at once, when the requirements are particularly uncertain. This statement rings so true to me that I really hope there exists a fleshed out version of this theory, with examples to prove it and maybe a catchy name, etc. Where I am now, I've literally participated in an identical thing being built in two ways at two different times: - The first time, I was the initial full-stack dev, along with one other guy (we were more of a duo... we paired a lot and worked pretty fluidly, it was kind of a 2-person equivalent of a single-person experiment.) The result was finished in 3 weeks and was flimsy but cohesive. Eventually the team was reduced to just me and I carried out the project for a few more months before a proper "team" was on board. - Then, the company noticed what we had done, decided that a bunch of other people had done similar things (it's a large company, after all), and then a 250-person organization was formed to write an MVP that was largely identical in scope. I wasn't in any leadership position in this new org, so nobody really cared that I had experience in this. I was reduced to writing a tiny insignificant part of the larger whole while our director drove the requirements. We're 10 months in and haven't shipped the first milestone yet. In the first example, we were almost too successful. The resulting product was used by thousands of people, for important things, with a lot of satisfaction and kudos from the users. But the total size of the team never really exceeded 5-10 people, so it got to the point where we were burned out supporting it, and there weren't enough reserves to call in to help because of the "second system" distracting everyone: In the second case, we don't have our first customer yet (although we've only kind of "soft" launched.) We did a massively half-assed attempt at agile that was basically "waterfall, but more vague, and please work harder", where we kinda half-assed came up with requirements, split everything up into 10-15 major "tentpoles", each of which was developed by separate teams. 6 months later we decided to start "integrating" all of it. 4 months after that, things finally kinda sorta work end-to-end. I've gone through a ton of self doubt through the process. In the first case, it worked only because there was almost no communication: we just did what we felt like, explored, and we were lucky that the end result worked. "Clearly, this will never scale, and is no way to run a real software product", I remember thinking. When the org got huge and we did our second system, I thought "Finally, I can learn to do what real software devs do and work for a big team with communication and requirements, etc". And inevitably when the result is a big pile of shit, I can't shake the feeling "this would've been better if I knew how to do real software development and work with a large team." Self loathing ensues. So I witnessed the pendulum swing each way. The first way was massively successful, but I suspect isn't sustainable (the product is withering due to lack of support now.) The second isn't successful at all, and is a complete mess, but maybe it'll be better with time. The only thing I know for sure is that few companies in the world can afford the amount of wasted time and energy we've spent on the second system. I suspect the real world works more like the first case but I don't have enough experience to know. I can't shake the thoughts of "I haven't seen real software development yet", and I don't know how much validity there is behind those doubts.

vemv 10y ago
Wow, the numbers (headcount / users / allocated time) speak alone! Thanks for sharing.
ebiester 10y ago
> Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. > Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. http://agilemanifesto.org/principles.html http://agilemanifesto.org/principles.html It sounds like the system started off as agile and the second system lost the plot.

dasmoth 10y ago

Perfectly put. I've been trying to push this kind of thinking recently. Most successful big projects grow out of a successful small project.

vemv 10y ago
> Most successful big projects grow out of a successful small project. This is probably true, one could even say that forming a big team from day one is cargo-culting others' success.