Classic SE Mistakes (1996) | Hacker News Reader

Classic SE Mistakes (1996)

cs.nmsu.edu

77 pointsarpa46 comments

Mods: missed that the post linked to is actually a repost of an article written in 1996 because almost 30 years later it still rings true to some orgs i've been working with.

Can we change the (2021) to (1996) please?

Also the source should point to the author’s site.

“Classic Mistakes”, Steve McConnell https://stevemcconnell.com/articles/classic-mistakes/

That’s only a limited subset of the mistakes, and the article is linking to the correct source on archive.org.

Sorry, I thought I was following the guidelines correctly:

> Please submit the original source. If a post reports on something found on another site, submit the latter.

(I also didn’t realize that the content didn’t match. Mea culpa.)

For some additional context on why the new list has fewer items. From the parent link:

> Here are my nominations for software’s top 12 classic mistakes.

Additionally:

> To make the list of classic mistakes even more useful, in 2007 Construx consultants update the list of Classic Mistakes based on Construx’s work with hundreds of clients since 1996. The following mistakes were added:

- Confusing estimates with targets

- Excessive multi-tasking

- Assuming global development has a negligible impact on total effort

- Unclear project vision

- Trusting the map more than the terrain

- Outsourcing to reduce cost

- Letting a team go dark (replaces the previous “lack of management controls”)

These additions and changes produced a total of 42 classic mistakes.

Construx then conducted a survey to determine how frequent and how serious these classic mistakes are.

“Software Development’s Classic Mistakes 2008”. (PDF) https://www.construx.com/wp-content/uploads/2020/04/CxWhiteP...

They could tag it 2026 too. I bet anything that all 36 points will still be true. Or 2036, 2046, etc.

> #6: Noisy, crowded offices.

I really do wonder why this point hasn't led to outright abolishment of open-plan offices.

WFH

I remember the last time this discussion came up at work and half the people where saying "We don't need special quiet offices at work, since if I want quiet concentration I'll just work from home" and the other half "No! The whole reason I come into the office rather than WFH is to get quiet concentration".

It’s abundantly clear to us that the office is the only refuge some employees have from their own lives - whether that’s the demands of child care one one extreme to loneliness on the other. As a small company, I think the office is a benefit and employee investment rather than a prison or salt mine.

I suspect it is too expensive to build closed offices for everyone. But what I don’t understand is why there are (almost) never a mix. A large open office room for normal work but also have a good portion of offices available for deep work that can be used on an ad-hoc basis.

Those offices have a tendency to become unofficial "permanent" offices, often "owned" by management.

Besides being a far cheaper option, the management-types making the decision typically benefits from an open floor plan office.

Their entire job revolves around communication with various different people around the office. Rarely ever does such a job demand focus time.

They are also typically extroverts who feel energized in a bustling office.

We now have a 30-70% mix silence room versus team open plan. The silence room also is open plan but with library rules. And the walls are sounds proofed.

Does it help? (genuine question)

Oh yes forgot to add that. It is amazing. You either sit down in the quiet place for dedicated work. Or you sit in the normal area and are open for questions but also to pick up what is being discussed. People do respect the library rules. Equipment like desks and monitors is the same as well. Although I think the silent room could be a bit denser in desks.

It turns out developer performance is not that important.

When I got my own office after having spent a couple of years in either an open-plan or a room with 3-4 other people, I remember thinking "Wow, this is what productivity feels like!"

I don't think it's about money. Software engineer salaries are very high, and cubicles are a compromise that still saves space. I think it's because for most people, procrastination reduces output a lot more than distraction and noise, and they procrastinate less when everyone can see their screen.

I had to read way too much of this before realizing that SE means software engineering.

I was kinda hoping it was about the Mac SE or the Mac Classic

I had to read this comment to find out.

I parsed "Classic SE" as "The first version of iPhone SE"

Funny, I thought Macintosh SE

It was pretty much flawless. :)

If you are coming from a Computer Engineering background or within a IEEE area of influence then SE is used everywhere as an acronym for Software Engineering.

I assume that if you are coming from Computer Science background you are not so caught up on making everyone aware that what you're doing is Engineering, so Software suffices.

Wow if these were "classic" mistakes when this was written in 1996, they're positively antique now. We've made so much progress in being able to build more complex things and yet we're still humans often making similar mistakes again and again. Software is hard.

> #33: Silver-bullet syndrome

> #34: Overestimated savings from new tools or methods

Yep, time and time again.

Most software isn't hard at all

Software is hard but more specifically it's human behavior - coordination and communication between contributors and teams to be exact

They're all management mistakes, as far as I can see. And the repeated references to De Marco are telling.

It reminds me in some ways of this article from HBR first published in 1981 https://hbr.org/1981/09/portfolio-approach-to-information-sy...

2002 web page, quoting his 1996 book:

https://web.archive.org/web/20021231112332/http://www.stevem...

I was nodding along at most of these - it's a bit like reading a horoscope. However when I got to the part on heroics I kind of woke from my slumber and I was left wondering if either it was a bunch of BS or I might need to pay more heed. For example I really don't understand the meaning of quotes such as "Tom DeMarco says, can-do attitudes escalate minor setback into true disasters (DeMarco 1995)."

Boss: Hey $employee, I see in my report we've been having a lot of problems with code not terminating. I need you to build a function that finds if an arbitrary function will halt and deploy that into production ASAP. I've already promised sales this will come and I'm on my way to write a press release announcing my brilliant feature!

Employee A: Yes sir! I'll get right on it!

Employee B: I don't know, boss. This is basically a pretty well studied problem called the halting problem, and I'm not sure we'll be able to build this all too easily even if we try really hard...

Employee C: we need to discuss the arbitrary part.

I think most real-world business processes can be proven to halt, assuming inputs are finite.

(When was the last time you wrote a while or repeat until loop, or a recursive function that didn’t iterate over an input?

> (When was the last time you wrote a while or repeat until loop, or a recursive function that didn’t iterate over an input?

Iterating until a convergence criteria is met is fairly common in numerical calculations.

It's also fairly common when dealing with graphs that may not have a beginning or an end in a conventional sense. PageRank does both of these things, for example.

Thanks for the example.

The tricky part here is convincing the CTO that the investors know these are classic mistakes. A common theme in the good war stories is that the developers can all see it coming a mile away, and sometimes the immediate leadership know if they care about getting productive results rather than responding with local-optimum politics.

"The common denominator in this list is that you won’t necessarily get rapid development if you avoid the mistake, but you will definitely get slow development if you don’t avoid it."

My current hobby horse/reductionist take on almost everything in life is that we are great at identifying problems and trash at fixing them.

Wow this is great and summarizes so many things I was vaguely aware of but couldn’t name as clearly.

Do they teach this at SE courses, or at any course that could lead to management positions? And if they do, can young people (with still limited experience of the world and interactions between people) really understand it?

Wow I would write how much I agree with all of these points based on my experience but I’d effectively be copying the page!

Every single one of these points is still incredibly relevant today.

Except for #36, not much has changed in 30+ years.

Per #20: Weeks of programming can save you days of planning!

Corallary: Hours of programming can sometimes save days of planning.

Reply on news.ycombinator.com