4 ms·

Based on my personal experience, most projects are doomed from the start due to these 2 MAJOR problems: 1. Not prioritizing the task of gathering, decomposing

by cvs268 10y ago

Based on my personal experience, most projects are doomed from the start due to these 2 MAJOR problems: 1. Not prioritizing the task of gathering, decomposing and documenting use-cases at the project kick-off. 2. Chronically under-estimating effort required. [1] http://thecodeartist.blogspot.com/2015/04/use-case-is-everything.html http://thecodeartist.blogspot.com/2015/04/use-case-is-everyt... [2] http://thecodeartist.blogspot.com/2017/04/effort-estimation.html http://thecodeartist.blogspot.com/2017/04/effort-estimation....

fiftyacorn 10y ago
I dont think its "under-estimating" as much as to get buy-in in a corporate environment means promising to over-deliver Architects/Developers can also be their own worst enemy - chosing a new stack over the existing stack
- cvs268 10y ago
  That too. However most of us tend to be overtly optimistic about the possibility that something will work as expected. Also we tend to forget the secondary tasks involved[3]. Also the fact that there is usually an expected schedule/due-date that are presented before being asked for estimates, people tend to invariably try to fit the effort-estimate into the pre-determined schedule subconsciously neglecting the secondary tasks. Its like when asked if i can cook a turkey-dinner in 2hours, i say - "looks do-able, i can try...". Completely forgetting the fact that i am being expected to raise it from an egg, and take care of it for a few months first. [3] Slide 8 - https://www.slideshare.net/cvs26/effort-estimation-73647698/8 https://www.slideshare.net/cvs26/effort-estimation-73647698/...
- humanrebar 10y ago
  > Architects/Developers can also be their own worst enemy - chosing a new stack over the existing stack Or doubling down on existing tech (and technical debt) instead of keeping their options open. One of the problems with agile development processes is that they're not paired with agile design principles.
BaronSamedi 10y ago
I often see these as well. I would even go so far as to say these problems are the rule rather than the exception. Why is software development still so high risk? I don't know the answer but it seems to me that software development is much too bespoke. Take a relatively simple case of web store front development. What if the development company said, OK, for your store you can have option A or option B. Period. The developer doesn't gather requirements at all, and all the tools and libraries are known and have been used before. The customer gets to pick a few options like when you buy a car (e.g., say some look&feel options). This is a low risk, predictable, "there's only one way to do it" approach. I'd like to see software development become vastly more predictable and stable. This will bore some developers who always want to try the latest framework and technology, but novelty adds risk.

by cvs268 10y ago

fiftyacorn 10y ago

I dont think its "under-estimating" as much as to get buy-in in a corporate environment means promising to over-deliver Architects/Developers can also be their own worst enemy - chosing a new stack over the existing stack

cvs268 10y ago
That too. However most of us tend to be overtly optimistic about the possibility that something will work as expected. Also we tend to forget the secondary tasks involved[3]. Also the fact that there is usually an expected schedule/due-date that are presented before being asked for estimates, people tend to invariably try to fit the effort-estimate into the pre-determined schedule subconsciously neglecting the secondary tasks. Its like when asked if i can cook a turkey-dinner in 2hours, i say - "looks do-able, i can try...". Completely forgetting the fact that i am being expected to raise it from an egg, and take care of it for a few months first. [3] Slide 8 - https://www.slideshare.net/cvs26/effort-estimation-73647698/8 https://www.slideshare.net/cvs26/effort-estimation-73647698/...
humanrebar 10y ago
> Architects/Developers can also be their own worst enemy - chosing a new stack over the existing stack Or doubling down on existing tech (and technical debt) instead of keeping their options open. One of the problems with agile development processes is that they're not paired with agile design principles.

BaronSamedi 10y ago

I often see these as well. I would even go so far as to say these problems are the rule rather than the exception. Why is software development still so high risk? I don't know the answer but it seems to me that software development is much too bespoke. Take a relatively simple case of web store front development. What if the development company said, OK, for your store you can have option A or option B. Period. The developer doesn't gather requirements at all, and all the tools and libraries are known and have been used before. The customer gets to pick a few options like when you buy a car (e.g., say some look&feel options). This is a low risk, predictable, "there's only one way to do it" approach. I'd like to see software development become vastly more predictable and stable. This will bore some developers who always want to try the latest framework and technology, but novelty adds risk.