251–260 of 419 posts
Earlier quoted context omitted.
> "Plans" can never be set in stone Setting plans in stone was the entire Waterfall Methodology where contracts had requirements and milestones locked in and any deviation meant heavy penalties.
Not when I have done waterfall - each waterfall phase can iterate
Earlier quoted context omitted.
The corporate culture serves a very specific purpose of lowering the self-esteem of the 10x folks, keeping them at their place doing 10x work at 1x salary until they burn out. This is scalable, predictable, and serves management's interests well. It's just if you happen to be a 10x guy, for the sake of your own sanity, learn how to run a business and get out of the corporate swamp. Nothing else will bring you happine…
People often forget that the 10x guy is 10x only in the domain he’s been working on, and many chores has been taken away from him by his manager and given to someone else. It is fairly easy to make a 10x someone closer to a 1x just by changing his tasks and giving more chores like CR, bug fixes, more mundane features or GUI etc. Sure it will often be better quality but in areas where it matters less.
But however they got there it took time, it's something that can be cultivated as long as folks aren't treated as fungible.
"Who is going to do it?" is always my first question whenever I am asked to estimate a piece of work. PMs/EMs are usually taken aback by the response, as if we are all supposed to pretend that all dev "resources" are equal. Yet reality doesn't fit into neat planning spreadsheets or burndown graphs, so often gets ignored.
Earlier quoted context omitted.
> So show me a methodology that mere mortals can implement successfully. Commit to a deliverable or a deadline, but never both.
I'm not all to familiar with this kind of thing so I could be missing something, but what is a deadline without a deliverable? Surely "We will do something (literally "something", not a stand-in for X) and it will take a month" is worth nothing?
So we committed to a deadline, but not a single deliverable. Scope would shrink and grow as delivery of each component progressed. Well in advance, for each major sporting event in each country where we operated, we would scope out literally every single thing we'd like to deliver, and then start work on the components in priority order. In each planning session as the event approaches we'd appraise whether we still have time to realistically deliver the next priority thing, and if not we'd skip it and move to the next - those that got missed out could wait until the following year (when the major features already delivered would need to evolve, not be implemented from scratch).
I learnt a lot from working on sports. Having third party deadlines that no-one could bitch about made us an extremely effective team at planning, estimating, and ruthless scope reduction.
Earlier quoted context omitted.
Absolutely Categorically Wrong! This has been so endlessly repeated without thought that people assume it is a fact when the Truth is far from it. Excerpts from wikipedia - https://en.wikipedia.org/wiki/Waterfall_model ; * In 1983 the paper was republished with a foreword by Benington explaining that the phases were on purpose organised according to the specialisation of tasks, and pointing out that the process was n…
Maybe you've never done big government contracts.
FYI, D.L.Parnas and Barry Boehm defined the field of Software Engineering. Almost all Govt./DoD standards are based on their research and writings.
I am a security engineer but have been a business leader from time to time. Business leaders often need to plan around dates- eg ”should we spend $50k announcing at conference Y in month Z, or should we wait until month A?” “Our competition just launched; will we be able to launch this quarter (the board wants to know, and we have to report material financial impact items quarterly or face SEC fines)?” Every team I h…
I just went through this, like... today. "Tell me what date task X will occur on." -- where task 'X' takes 5 minutes, but has a long list of pre-requisites that take 1-4 weeks each, sequentially , of which 100% our out of our control. ... That's not planning , that's fortune-telling . You may as well ask an Ouija board. Planning is making sure the the pre -requisites happen before you attempt to start the things that…
If you set your dependencies right, the dates would just slip by themselves, and it was easy to tell the bosses what slipped. Required a lot of printing and taping every week, and caused a ton of headache whenever people lied about their progress, and didn’t really work without a FTE project manager, but I have yet to see a supposedly better system actually work better on big projects.
Earlier quoted context omitted.
Using it or not using it would have taken longer?
Trying to use somebody else's code that does not solve the problem generally takes longer than writing it yourself.
Earlier quoted context omitted.
I mean, I get your point about the government but now you’re just complaining about how being insensitive to other people has the consequence of them fighting back.
Now you’re moving to assume that everything that has consequences is due to somebody being insensitive. It could also be, for example, that the person initiating consequences is entirely too sensitive.
"Who is going to do it?" is always my first question whenever I am asked to estimate a piece of work. PMs/EMs are usually taken aback by the response, as if we are all supposed to pretend that all dev "resources" are equal. Yet reality doesn't fit into neat planning spreadsheets or burndown graphs, so often gets ignored.
It may be a culture thing, but across the three companies I've worked at every estimate has been explicitly assuming a specific person handles it. Sometimes we've even given several estimates for the same task depending on who it gets assigned to. No one has ever found this odd. It's just obvious that different people have different skills and familiarity with different technologies or parts of the project.
Earlier quoted context omitted.
I got a harsh lesson about this in one of my very first jobs. A senior engineer on my team had built a rather complicated system. He was accordingly intimately familiar with all aspects of it. So when he estimated something on that system, it came with nearly all the discovery work already done. The PM proceeded to take an estimate from this person, hand it to a brand new hire, and expect them to deliver on that. Nee…
Yeah why do people have this view on programmers I just don't understand, every other single effing job in the world requires training and ramp-up, except programmers? And the fact that programming is depending on a unique pre-existing really complex code base further speaks against this. When my product owner quit, the new guy was working in parallel for 2 months to learn the ropes, noboby bats an eye, but a program…