SoylentNews

On Disenchantment with the Current State of Software Development

posted by chromas on Wednesday October 03 2018, @09:12PM   
from the the-future-is-now,-old-man dept.

canopic jug writes:

Nikita Prokopov has written a blog post detailing disenchantment with current software development. He has been writing software for 15 years and now regards the industry’s growing lack of care for efficiency, simplicity, and excellence as a problem to be solved. He addresses the following points one by one:

• Everything is unbearably slow
• Everything is too large
• Bitrot
• Half-baked products get shipped
• The same old problems recur again and again
• Most code has grown too complex to refactor
• Business is uninterested in improvement

---

Original Submission

• The old farts are still right The old farts are still right (Score: 5, Interesting) by Thexalon on Wednesday October 03 2018, @09:47PM (2 children)

  by Thexalon (636) on Wednesday October 03 2018, @09:47PM (#743689)

  These kinds of problems are absolutely nothing new in the field: Fred Brooks was writing about them decades ago, and they're just as true now as they were then.

  And he's right: Software today is largely a big bloated barely-functioning mess. And there's no simple method to eliminate the problems, because all the business incentives point towards slapping together a big bloated barely-functioning mess as quickly as possible and then engaging in the ever-popular practice of turd-polishing. There is, for instance, not much business case to be made for "let my developers spend 2 weeks fixing longstanding but minor bugs", and even less for "let my developers spend 3 months refactoring out the major problems with our system's design."

  It's also worth noting that the overwhelmingly dominant project management methodology is not Agile or Waterfall but what I've termed the UM approach:

  1. Underestimation: In this phase, the project manager assumes that every estimate given to them by the development team is multiplied by a factor of at least 2, and immediately cut a, say, 2 month timeline into 3 weeks. They then negotiate with their higher-ups to get approval for those 2 weeks - the higher-ups, naturally, think that the time estimate is inflated a bit, so they trim off the fat and cut it down a bit more to, say, 2 weeks. It is important to understand at this phase that if this underestimation does not occur, the project will not move forward, because approval for this project managers' pet project is competing with approval for other project manager's pet projects and the magically shrinking estimate is necessary for anything at all to happen. It should also be worth noting that the project manager's career depends on successfully completing projects, which means successfully getting higher-ups to approve said projects, so all the incentives encourage this behavior.
          
  2. Misery: In this phase, the project manager attempts to demand that the development team work harder and faster so they can get the project done in as close as possible to the time they told the higher-ups. Any lateness in this phase will be blamed on the developers, ideally either the very disposable junior-level developers or the old guys the company wanted to get rid of anyways. Regardless of what the project manager does, the job is guaranteed to take no less time than the developer's original estimate.
          
  3. UM: In this final phase, everybody makes excuses for why the project was not completed according to the project manager's schedule. This phase is characterized by people sitting in meetings going "Ummmm...", from whence it gets its name.

  This methodology will be dressed up with some cool-sounding name, but this is the approach used by every larger company and many smaller companies I've worked for.

  --
  The only thing that stops a bad guy with a compiler is a good guy with a compiler.

  Starting Score:	1		point
  Moderation		+4
  Insightful=2, Interesting=2, Total=4
  Extra 'Interesting' Modifier		0
  Karma-Bonus Modifier		+1
  Total Score:		5

• Not _Every_ Company, Blessedly (Score: 2) by MichaelDavidCrawford on Thursday October 04 2018, @04:15AM

  by MichaelDavidCrawford (2339) <mdcrawford@gmail.com> on Thursday October 04 2018, @04:15AM (#743847) Homepage Journal

  When I worked at Apple in the mid-nineties they were generally doing a good job at shipping quality software. I won't say on time or on budget, but what actually got into end-users' hands generally worked well.

  I credit some of this to Apple's requirement that all new projects have enthusiastic ERS sign-off: Engineering Requirements Summary. Not just the managers had to sign the ERSes but also the coders who would implement them.

  I read the ERS for the PowerPC Dynamic Recompiling 68k Emulator. I'm afraid that document was very much under NDA so I can't tell you how that emulator actually worked, but I can say its ERS was lucidly and concisely written, and at the time I felt that all I really required to have written that emulator myself was to have read the ERS.

  But I've also worked at places where it was all to common for the management to say "We'd make a killing if we published $SHINY Just In Time For Christmas". And in fact at one company that was a contract shop, the lawyers spent an extra month hammering out the contract for something that really did require it be in customer hands by black friday, so we all worked 24/7 to get it there.

  We really did, which speaks to the competence of our engineering staff, but I really would have liked to have beaten both parties' attorneys to death with my bare hands.

  --
  Yes I Have No Bananas. [gofundme.com]

  Parent

• Re:The old farts are still right (Score: 2) by termigator on Thursday October 04 2018, @05:42PM

  by termigator (4271) on Thursday October 04 2018, @05:42PM (#744209)

  I use the term “BIOYA” model. Pronounced boy-ya. Stands for, “Blow it out your ass,” since that is where most project time estimates come from.

  Parent