4 ms·

@12:19: https://youtu.be/UGhfB-NICzg?t=739 https://youtu.be/UGhfB-NICzg?t=739 > At this point, we threw the programmers an unexpected but not unrealistic curve

@12:19: https://youtu.be/UGhfB-NICzg?t=739 https://youtu.be/UGhfB-NICzg?t=739 > At this point, we threw the programmers an unexpected but not unrealistic curve. > Like a typical user, we asked them to add a feature not in the original spec. In this case, a button would recall all the trouble logs for a particular customer. > Using NeXT Step, the NeXT programmer completed the task in about 20 minutes. > [NeXT progammer discussing some details] > The sun programmer also estimated a time of 20 minutes, but it took about 45 before he was ready to test his version. This was about 20 hours in, which means that since they started on Wed, 30 October 1991 and assuming maximum 8-hour days, they have missed Halloween and would be at least halfway into Friday. The video states that the programmers finished on Sat, 2 November. The video goes on to state that the NeXT system enabled the NeXT programmer to add a number of features such as system fonts and button icons "for free", which goes to show that the video's intended audience are managers and executives of software development teams who would of course want faster development, ad hoc requests, and cost-free features. I personally would have been tempted to (╯°□°)╯︵ ┻━┻ once they announced a planned "unexpected" feature request because rather than train users and customers to frontload requirements in order to benefit from the design decisions that would be made as a result, the video encourages customers to believe their out-of-spec requests will be more quickly accommodated if only their programmers were using object-oriented NeXT Step. 25 years later, we know the truth about how easy it is to shoehorn in 11th-hour feature requests when using object-oriented code. EDIT: link to specified timecode; formatting; additional detail about date code was written.

m_mueller 10y ago
The main problem is that managers and users - lacking a mental model of the software - have no idea what's an easy problem and what's a hard problem (that would take lots of engineering). Thid creates unrealistic expectations.
- colejohnson66 10y ago
  The problem is people think that just because it's easy for them, it's easy for a computer. Obligatory xkcd[0]. "What!? I can clearly tell that's a bird! You mean to tell me that you can't make a computer do the same?" [0]: https://xkcd.com/1425/ https://xkcd.com/1425/
mwcampbell 10y ago
> they have missed Halloween I don't understand this part. You said you're assuming 8-hour work days. AFAIK, it's not at all common to take Halloween off from work. So what's the point of mentioning that day?
- mistersquid 10y ago
  Just that there are so few secular holidays in the US work context and Halloween is one of those non-holidays (like Cinco de Mayo in California) where people in the US will make an extra effort to spend time with friends and family.
- deleted 10y ago
  [deleted]
wpietri 10y ago
Has this ever worked? > than train users and customers to frontload requirements in order to benefit from the design decisions No matter how much training we give customers, the very best they can do is give us the reasonably foreseeable requirements. That was maybe possible for a couple of decades when our main job as an industry was to take well-evolved paper processes and put them on a computer. Even then, though, people were getting better results by shipping every few days in response to observing actual user experience. I don't think trying to frontload requirements works anymore, though. Startups are effectively machines for learning. We can't predict what learning will happen; if we could, we wouldn't be learning. And those startups are creating change for everybody else, making it impossible to know what competitive challenges might arise tomorrow. So I think it's time for us to stop pretending we can get everybody else to freeze the world just because it's more convenient for a particular set of design techniques. > 25 years later, we know the truth about how easy it is to shoehorn in 11th-hour feature requests when using object-oriented code. I was a NeXT programmer back then. 25 years later, it is much easier to add feature requests to OO codebases. The three big differences: automated testing is common and easy; refactoring a design is a well-understood process; and you can deploy to millions of people with zero additional cost or work beyond committing and pushing to master. Which in turn means that the whole notion of "11th hour" is dissolving. Which hour is the 11th if you're releasing a few times per day?
- mistersquid 10y ago
  Yours are all excellent points, especially in contexts that are close to or approaching continuous integration. However, many shops still release annually, quarterly, and bi-monthly. Also many shops don't have smooth sprints, their development processes being somewhere between Agile and Waterfall. I've worked in two such shops. I'm not naysaying you, just adding that I think your insights apply to a different model of development than the one I'm thinking about in my previous comment.

m_mueller 10y ago

The main problem is that managers and users - lacking a mental model of the software - have no idea what's an easy problem and what's a hard problem (that would take lots of engineering). Thid creates unrealistic expectations.

colejohnson66 10y ago
The problem is people think that just because it's easy for them, it's easy for a computer. Obligatory xkcd[0]. "What!? I can clearly tell that's a bird! You mean to tell me that you can't make a computer do the same?" [0]: https://xkcd.com/1425/ https://xkcd.com/1425/

mwcampbell 10y ago

> they have missed Halloween I don't understand this part. You said you're assuming 8-hour work days. AFAIK, it's not at all common to take Halloween off from work. So what's the point of mentioning that day?

mistersquid 10y ago
Just that there are so few secular holidays in the US work context and Halloween is one of those non-holidays (like Cinco de Mayo in California) where people in the US will make an extra effort to spend time with friends and family.
deleted 10y ago
[deleted]

wpietri 10y ago

Has this ever worked? > than train users and customers to frontload requirements in order to benefit from the design decisions No matter how much training we give customers, the very best they can do is give us the reasonably foreseeable requirements. That was maybe possible for a couple of decades when our main job as an industry was to take well-evolved paper processes and put them on a computer. Even then, though, people were getting better results by shipping every few days in response to observing actual user experience. I don't think trying to frontload requirements works anymore, though. Startups are effectively machines for learning. We can't predict what learning will happen; if we could, we wouldn't be learning. And those startups are creating change for everybody else, making it impossible to know what competitive challenges might arise tomorrow. So I think it's time for us to stop pretending we can get everybody else to freeze the world just because it's more convenient for a particular set of design techniques. > 25 years later, we know the truth about how easy it is to shoehorn in 11th-hour feature requests when using object-oriented code. I was a NeXT programmer back then. 25 years later, it is much easier to add feature requests to OO codebases. The three big differences: automated testing is common and easy; refactoring a design is a well-understood process; and you can deploy to millions of people with zero additional cost or work beyond committing and pushing to master. Which in turn means that the whole notion of "11th hour" is dissolving. Which hour is the 11th if you're releasing a few times per day?

mistersquid 10y ago
Yours are all excellent points, especially in contexts that are close to or approaching continuous integration. However, many shops still release annually, quarterly, and bi-monthly. Also many shops don't have smooth sprints, their development processes being somewhere between Agile and Waterfall. I've worked in two such shops. I'm not naysaying you, just adding that I think your insights apply to a different model of development than the one I'm thinking about in my previous comment.