See, I read the article's problem description and think, "Okay, a proof of concept is going to take 2-4 hours. A shippable product is probably going to take 5 t

See, I read the article's problem description and think, "Okay, a proof of concept is going to take 2-4 hours. A shippable product is probably going to take 5 to 10 times that long." IMX, it's not even necessarily feature creep. It's failure to stop and adequately understand what constitutes a minimum viable product. Not viable to sell on the marketplace. Merely viable to deliver to another user. There's a huge mistake in software development to think that the hard or complicated part is making the algorithm or understanding how your program will interact with it's own data or external data or hardware. That's seldom the actual hard part. The hard part is making it useful to a human being using the system. If it's just for me, I can use a proof of concept that I wrote in perpetuity. I can deal with how janky it is or the obtuse error messages it spits out. If anybody else has to use it, though, there needs to be a mental model for interacting with the software that is intuitive and comprehensible to the user that doesn't require them to have a comprehensive understanding of the underlying code, clases, and interfaces. This is the actual hard part of software development, and the bad part is that it's typically the part that nobody likes to do. That's the lesson the professor is trying to teach here. It's not how to write a program. Nearly any fool can do that. The lesson is: how to author deliverable software.