The Daily WTF: Curious Perversions in Information Technology

chubertdev · 2014-06-17 Reply Admin

The funny thing is that you can infer from the DBAs still working for Burt is that they are happy to be in an environment where any little change requires so much planning that it's a surprise that anything gets done. The DBAs most likely are content to sit at their desk all day and do everything but actual work.

DCRoss · 2014-06-17 Reply Admin

"Hey, lets get together at my desk and make sure we all agree on everything before going into the pre-meeting."

I only wish I was quoting Dilbert.

2014-06-17 Reply Admin

Fields with a maximum length in a database? Why would people use a system like that?

2014-06-17 Reply Admin

Was it only me who read CMNF instead of CMDB?

2014-06-17 Reply Admin

PPete:
Was it only me who read CMNF instead of CMDB?

Yep.

2014-06-17 Reply Admin

Sorry this comment is late, I was in a meeting.

2014-06-17 Reply Admin

Stuart:
Sorry this comment is late, I was in a meeting.

You must not be very important if you feel like you need to apologise for being late to the meeting. And if you were really important, the meeting would start over when you arrived (not officially, but we'd still have to re-cover anything that we'd already discussed).

PedanticCurmudgeon · 2014-06-17 Reply Admin

PPete:
Was it only me who read CMNF instead of CMDB?

Yes, but a visit to your local "gentleman's club" should fix that issue.

2014-06-17 Reply Admin

anonymous:
You must not be very important if you feel like you need to apologise for being late to the meeting. And if you were really important, the meeting would start over when you arrived (not officially, but we'd still have to re-cover anything that we'd already discussed).

If I wasn't important I would just sneak in and hide in the corner without making a sound, ergo I must be important.

2014-06-17 Reply Admin

During my short stint as a DBA I never called a meeting to discuss changes in the DB architecture. I just implemented the requested change, then cleared my calendar for all the meetings about why the applications suddenly didn't work any more.

Did I mention that it was a short stint? It was.

Captain Oblivious · 2014-06-17 Reply Admin

C:
eViLegion:
Obviously it's the fact that when the DB went wrong, the guy in charge took all of his techs away from the problem and locked them out from solving it (until they had a plan to solve it), without anyone being allowed to triage the issue.
It's like getting to Accident & Emergency, only to find the staff won't see you until they're 100% sure what's wrong.
No, it's like getting to Accident & Emergency, only to find the staff won't see you until they're 100% sure they have a plan for each of the possible scenarios about what could be wrong.

That's called "going to medical school", and it's essential to getting a job in Accident & Emergency.

DCRoss · 2014-06-17 Reply Admin

anonymous:
Stuart:
Sorry this comment is late, I was in a meeting.
You must not be very important if you feel like you need to apologise for being late to the meeting. And if you were really important, the meeting would start over when you arrived (not officially, but we'd still have to re-cover anything that we'd already discussed).

If you are truly important, the meetings will come to you.

They may bring donuts, or they may bring pitchforks and torches. It all depends on what is on the agenda.

HardwareGeek · 2014-06-17 Reply Admin

I'm sure glad I work for Bert, not Burt.

2014-06-17 Reply Admin

At one company I was at, the managers held a meeting to discuss why efficiency was so low. They came to the conclusion it was because they were having too many meetings. The solution was to hold a meeting to discuss what to do about it.

2014-06-17 Reply Admin

Maj najm:
Ziplodocus:
ANON:
faoileag:
tl;dr What is the wtf supposed to be?

I'm also not sure. Maybe we should have a meeting to discuss it.

Lets arrange a meeting to discuss the best time to arrange a meeting.

I've actually been dragged into a meeting where the sole point on the agenda was to decide when a meeting could be held. At the time I was working on a top priority issue that was causing revenue loss in the millions per hour. the meeting planned was to agree that everyone was working on what they said they were working on, pretty much. And everyone that was to be called to the meeting being planned was on the ad hoc meeting for planning the meeting. The meeting planning meeting lasted an hour.

A major shitstorm broke loose when I directed some very high level managmentorial ire to the micromanaging low level managers that held the meeting.

Where I work, some of us just ignore timesuck meetings when we have work to do. We claim "too busy, have clients to keep happy" and we get away with it, every time. Our clients pay us well, and the bosses not only know this fact, but also know why they pay us well.

2014-06-17 Reply Admin

QJo:
Where I work, some of us just ignore timesuck meetings when we have work to do. We claim "too busy, have clients to keep happy" and we get away with it, every time. Our clients pay us well, and the bosses not only know this fact, but also know *why* they pay us well.

We've have a weekly, half-hour "what are you guys working on?" coordination meeting between our various teams lately that has been helpful in opening up communication. But the other day, the project manager who scheduled the meeting wasn't there, so all us developers just shared what we needed to share and we were done in 5 minutes. We didn't need to spend extra time explaining things to those who don't understand.

That was the latest example to me that for managers, their "work" is having meetings. If they aren't in a meeting, they aren't "working".

2014-06-17 Reply Admin

Stuart:
anonymous:
You must not be very important if you feel like you need to apologise for being late to the meeting. And if you were really important, the meeting would start over when you arrived (not officially, but we'd still have to re-cover anything that we'd already discussed).

If I wasn't important I would just sneak in and hide in the corner without making a sound, ergo I must be important.

And there's your clue: the way you act doesn't make you important, it just reveals how important you think you are.

2014-06-17 Reply Admin

That's why you always have to hire managers in pairs. If you end up with an odd number of managers, then a worker has to meet with the odd manager out.

2014-06-17 Reply Admin

anonymous:
Stuart:
Sorry this comment is late, I was in a meeting.
You must not be very important if you feel like you need to apologise for being late to the meeting. And if you were really important, the meeting would start over when you arrived (not officially, but we'd still have to re-cover anything that we'd already discussed).

Yep. I can't count how many times I've seen this.

2014-06-17 Reply Admin

Sounds like some naughty DBA didn't go through proper IT best practices and ended up with:

-A Database that was set to FULL recovery mode when it shouldn't have.

-Some jerky developer/admin wrote bad code which kept the transaction open thus stopping the log from being truncated.

-A DBA setup some sort of HA solution which locks the log file.

TRWTF: -No alerts on log file growth. This causes a lot of performance issues if not addressed in many RDBMS.

-No Alerts on full disk space or full log files.

dkf · 2014-06-17 Reply Admin

anonymous:
You must not be very important if you feel like you need to apologise for being late to the meeting. And if you were really important, the meeting would start over when you arrived (not officially, but we'd still have to re-cover anything that we'd already discussed).

No. If you're really important, the meeting starts from scratch when you arrive, finishes when you leave, and anything discussed at other times is entirely irrelevant as it cannot possibly include a decision.

2014-06-17 Reply Admin

Pock Suppet:
someone:
just press the "accept" button in outlook. I believe that's how it works.
though sometimes that results in managers shouting about why you werent there
Hey, if it was important, they would have remembered to put a reminder on the appointment. Of course, you're required to immediately click Dismiss on all appointment popups.

Seriously...is it bad that I see my employer in about every third Dilbert and every fourth or fifth TDWTF? :(

I think Scott Adams and the makers of BuildMaster owe you big time for your contributions to TDWTF.

2014-06-17 Reply Admin

Regex:
What happened to the 50 characters?

They signed contracts to appear in upcoming Marvel Comics movies?

2014-06-17 Reply Admin

eViLegion:
Obviously it's the fact that when the DB went wrong, the guy in charge took all of his techs away from the problem and locked them out from solving it (until they had a plan to solve it), without anyone being allowed to triage the issue.
It's like getting to Accident & Emergency, only to find the staff won't see you until they're 100% sure what's wrong.

Btw, since it's an accident, I don't think holding a meeting without giving DBA time in front of machine to do fact finding will help.

I'm quite surprise to see that the problem is actually solved AFTER the meeting is hold.

2014-06-17 Reply Admin

Reductio Ad Ridiculousum:
anonymous:
Stuart:
Sorry this comment is late, I was in a meeting.
You must not be very important if you feel like you need to apologise for being late to the meeting. And if you were really important, the meeting would start over when you arrived (not officially, but we'd still have to re-cover anything that we'd already discussed).
Yep. I can't count how many times I've seen this.

The best reason for being late to a meeting is, of course, that you've only just got out of a meeting that was running late (it overran because they had to backtrack and re-cover old ground because someone was late to it).

2014-06-17 Reply Admin

Mr. AHole DBA:
Sounds like some naughty DBA didn't go through proper IT best practices and ended up with:
-A Database that was set to FULL recovery mode when it shouldn't have.

-Some jerky developer/admin wrote bad code which kept the transaction open thus stopping the log from being truncated.

-A DBA setup some sort of HA solution which locks the log file.

TRWTF: -No alerts on log file growth. This causes a lot of performance issues if not addressed in many RDBMS.

-No Alerts on full disk space or full log files.

Actually, there was an alert, but I missed it because my boss had called me into a meeting to discuss the meeting schedule.

2014-06-18 Reply Admin

C-Derb:
Biggest problem we have at my company is finding a conference room that is available on the scheduling calendar.
Oh sure, there's plenty of empty ones that don't appear to be in use, but they are all booked thanks to the magic of recurring meetings that are optional from day to day or week to week.

Pro Tip: If you are planning to cancel your weekly meeting, don't wait until 5 minutes after the start time to cancel it.

That is brilliant! I've set up recurring daily meetings for every meeting room in the building. Thank you, thank you!

2014-06-18 Reply Admin

anon:
C-Derb:
Biggest problem we have at my company is finding a conference room that is available on the scheduling calendar.
Oh sure, there's plenty of empty ones that don't appear to be in use, but they are all booked thanks to the magic of recurring meetings that are optional from day to day or week to week.

Pro Tip: If you are planning to cancel your weekly meeting, don't wait until 5 minutes after the start time to cancel it.

That is brilliant! I've set up recurring daily meetings for every meeting room in the building. Thank you, thank you!

You're obviously a fan of the conference call then.

https://www.youtube.com/watch?v=zbJAJEtNUX0

Nutster · 2014-06-18 Reply Admin

Burt's next meeting will be with his boss and a representative from Human Resources. The next meeting after that will be called a Job Interview.

Addendum (2014-06-18 10:25): Actually, in between these two meetings, there will be a meeting called a Welfare Qualification Interview.

DrPepper · 2014-06-18 Reply Admin

Amongst all the angst about meetings, everyone missed an important point -- the DBAs are responsible for the database, probably the most important asset the company owns. We, as developers, like to think of the DB as an extension/component of our software. It's not -- and the DBAs correctly examine change requests for effects beyond the scope of our immediate needs.

For example: Adding an index adds disk space requirements; slows down the write operations; requires additional backup resources (tapes?); might have implications for database mirroring. Creating the index might lock the table involved.

The value of the database, and the availability of the database, is quite high; and shouldn't be jeopardized by ad-hoc requests from developers.

2014-06-18 Reply Admin

I was alerted to the issue and got to work on opening the three tickets and making the two phone calls so I could get the ball rolling on a fix. Those are literal numbers.

And then I started getting IM's and phone calls demanding updates about what I was doing to fix the problem.

So the updates were "I am currently updating various managers and directors regarding the status of the issue. When I have finished with these updates, I will return to the process of opening the necessary tickets so that we can get started fixing the issue."

They weren't as amused as I was.

2014-06-18 Reply Admin

I have actually been in a few of those... it's like wtf really? Why can't we just do it now instead of discussing when we should discuss it....

2014-06-18 Reply Admin

Maj najm:
Ziplodocus:
ANON:
faoileag:
tl;dr What is the wtf supposed to be?

I'm also not sure. Maybe we should have a meeting to discuss it.

Lets arrange a meeting to discuss the best time to arrange a meeting.

I've actually been dragged into a meeting where the sole point on the agenda was to decide when a meeting could be held. At the time I was working on a top priority issue that was causing revenue loss in the millions per hour. the meeting planned was to agree that everyone was working on what they said they were working on, pretty much. And everyone that was to be called to the meeting being planned was on the ad hoc meeting for planning the meeting. The meeting planning meeting lasted an hour.

A major shitstorm broke loose when I directed some very high level managmentorial ire to the micromanaging low level managers that held the meeting.

Lucky. One of our customers requires these meetings. They are called FRB, Fault Review Boards, and usually end up being a total of 6 meetings when they are all said and done.

2014-06-18 Reply Admin

I really, really dislike DBAs. Hopefully, the column being changed from 25 to 50 was not typed as character (which allocates that amount of storage) but was instead typed as varchar which meanss that the amount of storage used depends on the size of the actual data, the data is just constrained to a maximum of 50 characters on insert/update.

Another time, on the first day after adding several hundred users to a user base of less than 100, login times went off the cliff, it was taking a user 20 minutes just to login. Our dba(s) were wanting to balance the table space between drives, talked about buying faster hardware, etc. I suggested adding an index to the user security table and was told it would not help. After a few minutes, I convinced the dba(s) to add the index, login time went down to seconds.

And I really dislike managers who try to solve problems through group think, if these meeting take more than 5 minutes, it is obvious that the first step is to actually define the problem. A nightly batch job was still running after several hours when it had been running in less than 5 minutes. Checking the logs showed that the time had been increasing each day for several weeks which coincided with a program revision. I got into trouble for stepping out to actually check the logs rather than sit with the headless chickens who were busy discussing possible causes of the slow running job.

2014-06-18 Reply Admin

The physical database is not a critical part of the business, the data inside the database is the business critical piece.

Indexing can be overdone, but having application performance where things are taking minutes/hours instead of seconds is unacceptable.

When the application/data is unusable due to performance, locking users out in order to add an index is a reasonable course of action, the users can not use the application/data anyway.

Anything that prevents users from adding and updating the business critical data is an issue, pretending that developers are making ad-hoc changes for the sake of a change is a sham. These developers are trying to make sure that the business can continue getting the data that is so valuable.

As far as disk storage cost, really, still beating that drum?

2014-06-18 Reply Admin

rob:
I really, really dislike DBAs. Hopefully, the column being changed from 25 to 50 was not typed as character (which allocates that amount of storage) but was instead typed as varchar which meanss that the amount of storage used depends on the size of the actual data, the data is just constrained to a maximum of 50 characters on insert/update.
Another time, on the first day after adding several hundred users to a user base of less than 100, login times went off the cliff, it was taking a user 20 minutes just to login. Our dba(s) were wanting to balance the table space between drives, talked about buying faster hardware, etc. I suggested adding an index to the user security table and was told it would not help. After a few minutes, I convinced the dba(s) to add the index, login time went down to seconds.

And I really dislike managers who try to solve problems through group think, if these meeting take more than 5 minutes, it is obvious that the first step is to actually define the problem. A nightly batch job was still running after several hours when it had been running in less than 5 minutes. Checking the logs showed that the time had been increasing each day for several weeks which coincided with a program revision. I got into trouble for stepping out to actually check the logs rather than sit with the headless chickens who were busy discussing possible causes of the slow running job.

Gosh, it sounds like you're working in an amateur shop that hires bottom of the barrel talent, from what you're describing. I'm not sure how you even ended up working there!

2014-06-18 Reply Admin

rob:
The physical database is not a critical part of the business, the data inside the database is the business critical piece.
Indexing can be overdone, but having application performance where things are taking minutes/hours instead of seconds is unacceptable.

When the application/data is unusable due to performance, locking users out in order to add an index is a reasonable course of action, the users can not use the application/data anyway.

Anything that prevents users from adding and updating the business critical data is an issue, pretending that developers are making ad-hoc changes for the sake of a change is a sham. These developers are trying to make sure that the business can continue getting the data that is so valuable.

As far as disk storage cost, really, still beating that drum?

Unless the developer has a good background in database design, knows index consolidation, knows how to check index statistics/usage/management, then they have no place being the word of authority on what gets indexed how.

By merely showing that 1 query all of a sudden performs better by changing an index, MIGHT mean that is the proper course of action but doesn't guarantee it, at all.

A lot of problems arise over time when people who don't know index internals have the authority to dictate how things get indexed.

IF you don't know index internals, I don't care what your opinion is about indexing or your 1 scenario. Just as you shouldn't give a damn what my opinion is on how you should write your code using what constructs/assemblies/languages, etc. You know your job, and the good DBA knows theirs. To pretend you know each others is not helpful.

By the way, damn right storage cost is still an issue. Just as you pointed out, it's not just the 'physical disk the database stays on' that's the only issue. Physical hard drives might be cheap (by the way, they aren't, not SAS or enterprise SSDs, they are actually quite expensive) but the cost to host them and the cost to access the data adds up. I realize you're not writing the check but let's not pretend it's not a constraint.

2014-06-19 Reply Admin

Right; however, the question is when should these concerns be taken into account, and whose responsibility is it? I, personally, would much rather see the roles of "database schema/query/... developer" and "production database caretaker" split apart, as the two jobs require a...fairly different set of traits, even though they both involve (different instances of, of course ;) the same software for the most part.

Also: does every last drop of data in the DB need to be on super-expensive SSDs or SAS drives? I suspect not...

CAPTCHA - suscipere: The database was suscipere to outages caused by the DBAs having to babysit the darn thing all the time.

2014-06-19 Reply Admin

Mr. AHole DBA:
Gosh, it sounds like you're working in an amateur shop that hires bottom of the barrel talent, from what you're describing. I'm not sure how you even ended up working there!

Actually I have worked in multiple shops over the last 30 years that either used Oracle (90%) or Informix. I have had the pleasure of working with several highly competent DBAs and the misfortune of working with less than qualified DBAs. The majority of my work has been as a system integrator/developer where the majority of the application was written and designed by an external vendor as a commercial product; most of the development that is done is either reports/queries, simple screen modifications or performance tuning related to the database.

the less than capable DBAs have made the following statements or errors.

"If I were to allocate more disk space (needed due to just simple application data growth), I would not have any spare space." This was on a dedicated server.
Deciding to change the security profile on a dozen production instances that had been in use for over 5 years, this particular change locked out hundreds of users. This was also done by a DBA with no notice.
Miss-installing the database software on a test server, fixing the install on that test server, then repeating the same mistake when configuring the production server. (the time to fix was days, this made the production cutover for 200 users have 4 more days of down time).
wanting to fix a performance problem (application is unusable) where users could not log in by wanting to spend a week getting new hardware and reconfiguring the database instead of just adding an index. This problem was caused by adding several hundred newly trained users to the production environment.

chubertdev · 2014-06-19 Reply Admin

rob:
2) Deciding to change the security profile on a dozen production instances that had been in use for over 5 years, this particular change locked out hundreds of users. This was also done by a DBA with no notice.

And during peak hours, of course.

2014-06-19 Reply Admin

chubertdev:
rob:
2) Deciding to change the security profile on a dozen production instances that had been in use for over 5 years, this particular change locked out hundreds of users. This was also done by a DBA with no notice.
And during peak hours, of course.

Why would you hire a DBA when Windows Update will do the same work for free?

chubertdev · 2014-06-19 Reply Admin

Norman Diamond:
chubertdev:
rob:
2) Deciding to change the security profile on a dozen production instances that had been in use for over 5 years, this particular change locked out hundreds of users. This was also done by a DBA with no notice.
And during peak hours, of course.
Why would you hire a DBA when Windows Update will do the same work for free?

Windows Update has a few orders of magnitude less entropy than a rogue/witless DBA.

2014-06-19 Reply Admin

rob:
Mr. AHole DBA:
Gosh, it sounds like you're working in an amateur shop that hires bottom of the barrel talent, from what you're describing. I'm not sure how you even ended up working there!

Actually I have worked in multiple shops over the last 30 years that either used Oracle (90%) or Informix. I have had the pleasure of working with several highly competent DBAs and the misfortune of working with less than qualified DBAs. The majority of my work has been as a system integrator/developer where the majority of the application was written and designed by an external vendor as a commercial product; most of the development that is done is either reports/queries, simple screen modifications or performance tuning related to the database.

the less than capable DBAs have made the following statements or errors.

"If I were to allocate more disk space (needed due to just simple application data growth), I would not have any spare space." This was on a dedicated server.

Deciding to change the security profile on a dozen production instances that had been in use for over 5 years, this particular change locked out hundreds of users. This was also done by a DBA with no notice.

Miss-installing the database software on a test server, fixing the install on that test server, then repeating the same mistake when configuring the production server. (the time to fix was days, this made the production cutover for 200 users have 4 more days of down time).

wanting to fix a performance problem (application is unusable) where users could not log in by wanting to spend a week getting new hardware and reconfiguring the database instead of just adding an index. This problem was caused by adding several hundred newly trained users to the production environment.

And this bad apple got the boot fast and hard I would hope? Working with a sucky insert IT job here past help desk is always a pain the rear. Sticking with a company that doesn't know the difference/puts up with it is TRWTF IMO.

Not saying you did or didn't, but just any highly skilled I.T. engineer can get a good job at the drop of a hat.

2014-06-19 Reply Admin

rob:
Mr. AHole DBA:
Gosh, it sounds like you're working in an amateur shop that hires bottom of the barrel talent, from what you're describing. I'm not sure how you even ended up working there!

Actually I have worked in multiple shops over the last 30 years that either used Oracle (90%) or Informix. I have had the pleasure of working with several highly competent DBAs and the misfortune of working with less than qualified DBAs. The majority of my work has been as a system integrator/developer where the majority of the application was written and designed by an external vendor as a commercial product; most of the development that is done is either reports/queries, simple screen modifications or performance tuning related to the database.

the less than capable DBAs have made the following statements or errors.

"If I were to allocate more disk space (needed due to just simple application data growth), I would not have any spare space." This was on a dedicated server.

Deciding to change the security profile on a dozen production instances that had been in use for over 5 years, this particular change locked out hundreds of users. This was also done by a DBA with no notice.

Miss-installing the database software on a test server, fixing the install on that test server, then repeating the same mistake when configuring the production server. (the time to fix was days, this made the production cutover for 200 users have 4 more days of down time).

wanting to fix a performance problem (application is unusable) where users could not log in by wanting to spend a week getting new hardware and reconfiguring the database instead of just adding an index. This problem was caused by adding several hundred newly trained users to the production environment.

And this bad apple got the boot fast and hard I would hope? Working with a sucky insert IT job here past help desk is always a pain the rear. Sticking with a company that doesn't know the difference/puts up with it is TRWTF IMO.

Not saying you did or didn't, but just any highly skilled I.T. engineer can get a good job at the drop of a hat.

2014-06-19 Reply Admin

chubertdev:
rob:
2) Deciding to change the security profile on a dozen production instances that had been in use for over 5 years, this particular change locked out hundreds of users. This was also done by a DBA with no notice.

And during peak hours, of course.

Did the company have proper CM policies in place? If so, was the idiot held responsible for ignoring them? If the company didn't have proper CM policies distributed, then was the idiot pointy haired boss held responsible?

Nutster · 2014-06-21 Reply Admin

The plan to fix a problem in 4 steps:

Identify the issue. What should be happening? What is actually happening instead? How can the user reproduce the problem?
Identify the actual problem. Brainstorm causes of the issue, based on the evidence already known. Investigate each idea, starting with the most plausible. Step through processes, if possible.
Fix the problem. Make repairs to the appropriate systems and test the fix to make sure you got it and did not create a new problem.
Mitigate the issue. What can be done to prevent problems like this from happening again? Better documentation? More training? More thorough training? Hardware upgrades?

By the way, if blame is to be assigned, it only shows up in the last step. Now get out there and solve the problem!

Addendum (2014-06-21 14:07): Whoops. It looks like I used training twice. More/better docs? Better policies? More thorough training? Hardware repairs/upgrades? Yeah, that's more along the lines.

Steve The Cynic · 2014-06-23 Reply Admin

ratchet freak:
faoileag:
tl;dr What is the wtf supposed to be?

That Burt blocked the DBAs from making a 5 minute fix by locking them in a conference room to "make a plan of action" for half a day. The end result was a preventable company wide shutdown fueled by a desire to hold meetings.

I really hope Burt's next meeting was with upper to discus all the meetings he was having.

I hear this: http://thedailywtf.com/Articles/Some-Call-Me%E2%80%A6-Tim.aspx

2014-06-24 Reply Admin

The DBA manager's actions are not within the guidelines of the fair labor standards act (in USA). Managers here cannot 'lock down' employees.

2014-06-25 Reply Admin

It's a long-standing management worldview that holding a meeting about a problem is equivalent to solving the problem.

For example, I was on a development project that ran over the time allotted by management (which was approximately 1/5 the time the development team had estimated), and management attempted to solve this problem by daily meetings where they grilled each developer on what they had done in the last day.

The developers (who had been told that their primary reward for the 80-hour work weeks they were now expected to put in was to keep their jobs) weren't complete fools and didn't respond with "Yesterday, I spent 3 hours explaining to you what I did the day before, and then spent another 10 hours doing my job. I haven't seen my family in months."

When the project was sorta-completed (in 2/5 of the time the development team had said they needed, without any truly glaring bugs), management patted themselves on the back for "maintaining tight control of the project" which they were certain was why it had been completed at all. The managers involved were promoted, while the development team received nothing at all for their 80-hour work weeks. For some reason that management couldn't understand, approximately 2/3 of the development staff quit within the next year.

2017-02-04 Reply Admin

one of the comments reminded me of a story: a manager tried to improve meeting attendance by establishing a FINE system: (minutes late*number of people in meeting) dollars. but less than a week later, the SAME manager was an hour late to a meeting with 100 people...

The Five Alarm Meeting

Leave a comment on “The Five Alarm Meeting”