Who works for the biggest idiots? Top this..

[pauldun170]

It amazes me how resistant most non-technical people are to anything related to formal requirements tracking (and this includes many CTO's). They either

1) Hate documentation in general and just want to fly by the seat of their pants. In other words, they have no fucking idea how to do their job.

2) Hate having documentation that could hold them accountable later on. Sucks when you can't blame IT/IS when a client kicks in your door because your product/solution doesn't do XYZ.

Usually it's some combination of both, though. I worked for a VP for a long time who mostly fit with #1, and it drove me insane. I have no idea how he got to that level, but he had zero knowledge of SLDC management, Project Management, or anything that resembled a professional approach to modern software development. I tried time and time again to bring him up to speed, but he would immediately go into "deer in the headlights" mode. He was fired a year and a half ago, about a month after I quit.

That's what happens when you make an AS/400 guy a VP and said guy decides his learning period has ended.

Right now I have a client who's very resistant to formal requirements documentation, and that has induced all the standard pitfalls. When I was first brought in, I tried to use a formal approach but was told "that's now really how we do it here." So I did it their way for about 6 months. As time when on, I would be asked more and more "I can't remember - what did we decide this was supposed to do?"

I came up with a sneaky-ish solution: my team doesn't create anything until an email is distributed to the stakeholders outlining the requirements, and said stakeholders reply with "do it."

So it's not a word document :shrug:

I'll get them there...

I worked for a heavily matrixed organization and it was awesome. Everyone was accountable for everything they said, did, and agreed to. No more, no less. Nowhere to hide if you fucked up, regardless if you were a developer, technical lead, BA, PM, QA, etc.

Everything was awesome :whiste:

^
All of that

 

[child of wonder]

Back when I worked for a bank, we had a security audit performed by a 3rd party and they came back with a laundry list of security vulnerabilities in our organization. I was tasked with going through the list and determining how to fix them.

One flaw was that our external routers had SSH and Telnet open to the internet. I looked at the configs and there was no ACL whatsoever on the devices. I asked my boss if he knew about this and this was his response:

"Yeah, I deleted the ACLs. They're a big pain in the ass to maintain. Besides, we back up the configs so if someone hacks into them we'll just restore the router. No big deal."

I wanted to put that up on a billboard advertising our bank.

 

[Markbnj]

Yeah, it's all the business person's fault. It has nothing to do with IT not understanding the requirements, even though they're shaking their heads throughout the initial requirements assessment, right?

In my experience the requirements are usually not at all difficult to understand. They're just difficult to commit to. Business people think that software is mutable, because its just a bunch of guys typing crap into a computer after all. They would never treat the construction of a new building that they actually spend less on with anything like the cavalier approaches they will apply to software. My $.02.

 

[Albatross]

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

 

[natto fire]

That's how most software works these days? Do you have proof for that (professional experience on open source or commercial products) and can you elaborate? I'm guessing the answer to that is a big "fuck no" and you're clueless.

Buy any piece of software, or even a gaming console, or anything that just came out. The first thing it wants to do before you even use it is patch. If they actually would test stuff before release it would not need so many patches so early.

Apparently not clueless on how to use anecdotal evidence, though. RS spouting off about random stuff he lacks first hand knowledge is nothing new, at least.

 

[PG]

The top guy where I work isn't an idiot but he is difficult to deal with. He sometimes plays dumb and/or changes his story about what he said or ordered people to do. He once told me to do something and then a few weeks later asked me why I did it. He is very slippery because his initial statements are always verbal. With nothing documented in writing it's very frustrating.

I did discuss this with a co-worker once and she said he was known for that. Her method of dealing with it was to send him an email documenting verbal orders/conversations. She said that took care of almost all the BS from him.

I haven't been so good about taking her advice, usually because he plays dumb or flip flops on the most trivial or simple issues. I just don't know why he goes through the work to play these games. There doesn't seem to be any reason for it or any way he can benefit from it.

 

[MagnusTheBrewer]

The top guy where I work isn't an idiot but he is difficult to deal with. He sometimes plays dumb and/or changes his story about what he said or ordered people to do. He once told me to do something and then a few weeks later asked me why I did it. He is very slippery because his initial statements are always verbal. With nothing documented in writing it's very frustrating.

I did discuss this with a co-worker once and she said he was known for that. Her method of dealing with it was to send him an email documenting verbal orders/conversations. She said that took care of almost all the BS from him.

I haven't been so good about taking her advice, usually because he plays dumb or flip flops on the most trivial or simple issues. I just don't know why he goes through the work to play these games. There doesn't seem to be any reason for it or any way he can benefit from it.

He's a pot stirrer. He believes the only way to keep employees engaged is to upset the status quo. A sure sign of a bad manager.