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.
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.
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.
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.
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.
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.
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 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.
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.
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...
> (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.
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.
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?
Can we change the (2021) to (1996) please?