3 ms·
The CTO is a developer, with ~ 17 years of experience, I believe. Although I don't think he wrote any substantial amount of code at all in our product (from the
by viredfox 12y ago
The CTO is a developer, with ~ 17 years of experience, I believe. Although I don't think he wrote any substantial amount of code at all in our product (from the start).
We're an end-user consumer site, and the rate has been stable in term of absolute number (so decreasing in %).
I called the process waterfall because it's a strict requirement - implementation - QA. I'm not particularly concerned with the tech stack, that was just a personal gripe rather than anything.
- hrttrht 12y agoDoes that mean he wants to run things like he did 17 years ago?
- ams6110 12y agoTraditional waterfall would not be releasing every 4-5 weeks. Traditional waterfall would attempt to define all the requirements up front, freeze the specification, then implement/test, then (in theory) the product is "done." This sounds like some form of iterative/agile development, though perhaps not ideally managed. Standups are generally not 1 hour (but they are not part of waterfall at all). An agile process can start to look like waterfall if you zoom way in. At some point you have to define what it is you're building, then build it, then QA it. Agile just does this in short cycles based on user stories, while traditional waterfall would attempt to define (as much as possible) ALL the requirements up front.
- viredfox 12y agoNormally we have a scope of what we want to do (ie. Let's redo the homepage and the login page). Then the product team group up and hash out the requirement, which is then sent to the developer. Although there are iterative changes in design, I actually don't know why the changes were made most of the time (they are not because of the implemented demo by the dev, the product team only starts seeing at the same time of QA)