6 ms·

Classic SE Mistakes (1996)

77 points by arpa 4y ago

NegativeLatency 4y ago
Wow this is great and summarizes so many things I was vaguely aware of but couldn’t name as clearly.
loudgas 4y ago
I had to read way too much of this before realizing that SE means software engineering.
- NegativeLatency 4y ago
  I was kinda hoping it was about the Mac SE or the Mac Classic
- Manfred 4y ago
  I had to read this comment to find out.
- donpott 4y ago
  I parsed "Classic SE" as "The first version of iPhone SE"
  - doctor_eval 4y ago
    Funny, I thought Macintosh SE
  - layer8 4y ago
    It was pretty much flawless. :)
- DoingIsLearning 4y ago
  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.
lastofthemojito 4y ago
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.
- jamesfinlayson 4y ago
  > #33: Silver-bullet syndrome > #34: Overestimated savings from new tools or methods Yep, time and time again.
- jbverschoor 4y ago
  Most software isn't hard at all
- cee_el123 4y ago
  Software is hard but more specifically it's human behavior - coordination and communication between contributors and teams to be exact
- denton-scratch 4y ago
  They're all management mistakes, as far as I can see. And the repeated references to De Marco are telling.
arpa 4y ago
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?
- jt2190 4y ago
  Also the source should point to the author’s site. “Classic Mistakes”, Steve McConnell https://stevemcconnell.com/articles/classic-mistakes/ https://stevemcconnell.com/articles/classic-mistakes/
  - layer8 4y ago
    That’s only a limited subset of the mistakes, and the article is linking to the correct source on archive.org.
    - jt2190 4y ago
      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.)
  - deleted 4y ago
    [deleted]
  - jt2190 4y ago
    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/CxWhitePaper_ClassicMistakes.pdf https://www.construx.com/wp-content/uploads/2020/04/CxWhiteP...
Foobar8568 4y ago
It reminds me in some ways of this article from HBR first published in 1981 https://hbr.org/1981/09/portfolio-approach-to-information-systems https://hbr.org/1981/09/portfolio-approach-to-information-sy...
robga 4y ago
2002 web page, quoting his 1996 book: https://web.archive.org/web/20021231112332/http://www.stevemcconnell.com/rdenum.htm https://web.archive.org/web/20021231112332/http://www.stevem...
roenxi 4y ago
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.
djmips 4y ago
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)."
- marginalia_nu 4y ago
  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...
  - djmips 4y ago
    Thanks for the example.
  - Someone 4y ago
    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?
    - marginalia_nu 4y ago
      > (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.
tempodox 4y ago
> #6: Noisy, crowded offices. I really do wonder why this point hasn't led to outright abolishment of open-plan offices.
- jbverschoor 4y ago
  WFH
  - deleted 4y ago
    [deleted]
  - dagw 4y ago
    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".
    - aksss 4y ago
      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.
- Cwizard 4y ago
  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.
  - anon2351 4y ago
    Those offices have a tendency to become unofficial "permanent" offices, often "owned" by management.
deleted 4y ago
[deleted]
lloydatkinson 4y ago
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.
papandada 4y ago
"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.
layer8 4y ago
Except for #36, not much has changed in 30+ years.
kwertyoowiyop 4y ago
Per #20: Weeks of programming can save you days of planning!
- xnx 4y ago
  Corallary: Hours of programming can sometimes save days of planning.
pmontra 4y ago
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?

77 points by arpa 4y ago

NegativeLatency 4y ago

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

loudgas 4y ago

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

NegativeLatency 4y ago
I was kinda hoping it was about the Mac SE or the Mac Classic
Manfred 4y ago
I had to read this comment to find out.
donpott 4y ago
I parsed "Classic SE" as "The first version of iPhone SE"
- doctor_eval 4y ago
  Funny, I thought Macintosh SE
- layer8 4y ago
  It was pretty much flawless. :)
DoingIsLearning 4y ago
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.

lastofthemojito 4y ago

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.

jamesfinlayson 4y ago
> #33: Silver-bullet syndrome > #34: Overestimated savings from new tools or methods Yep, time and time again.
jbverschoor 4y ago
Most software isn't hard at all
cee_el123 4y ago
Software is hard but more specifically it's human behavior - coordination and communication between contributors and teams to be exact
denton-scratch 4y ago
They're all management mistakes, as far as I can see. And the repeated references to De Marco are telling.

arpa 4y ago

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?

jt2190 4y ago
Also the source should point to the author’s site. “Classic Mistakes”, Steve McConnell https://stevemcconnell.com/articles/classic-mistakes/ https://stevemcconnell.com/articles/classic-mistakes/
- layer8 4y ago
  That’s only a limited subset of the mistakes, and the article is linking to the correct source on archive.org.
  - jt2190 4y ago
    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.)
- deleted 4y ago
  [deleted]
- jt2190 4y ago
  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/CxWhitePaper_ClassicMistakes.pdf https://www.construx.com/wp-content/uploads/2020/04/CxWhiteP...

Foobar8568 4y ago

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

robga 4y ago

2002 web page, quoting his 1996 book: https://web.archive.org/web/20021231112332/http://www.stevemcconnell.com/rdenum.htm https://web.archive.org/web/20021231112332/http://www.stevem...

roenxi 4y ago

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.

djmips 4y ago

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)."

marginalia_nu 4y ago
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...
- djmips 4y ago
  Thanks for the example.
- Someone 4y ago
  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?
  - marginalia_nu 4y ago
    > (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.

tempodox 4y ago

> #6: Noisy, crowded offices. I really do wonder why this point hasn't led to outright abolishment of open-plan offices.

jbverschoor 4y ago
WFH
- deleted 4y ago
  [deleted]
- dagw 4y ago
  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".
  - aksss 4y ago
    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.
Cwizard 4y ago
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.
- anon2351 4y ago
  Those offices have a tendency to become unofficial "permanent" offices, often "owned" by management.

deleted 4y ago

[deleted]

lloydatkinson 4y ago

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.

papandada 4y ago

"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.

layer8 4y ago

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

kwertyoowiyop 4y ago

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

xnx 4y ago
Corallary: Hours of programming can sometimes save days of planning.

pmontra 4y ago

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?