How To Demoralize Employees: A DIY Guide for Terrible Companies
-
I moved 19 posts to an existing topic: Dashes (a.k.a. Blakey needs to fix contrast on his monitor)
It was just all the CSS stuff from last night. Sam finally fixed the ability to move posts to an existing topic...
-
I moved 19 posts to an existing topic: Dashes (a.k.a. Blakey needs to fix contrast on his monitor)
It was just all the CSS stuff from last night. Sam finally fixed the ability to move posts to an existing topic...
Shame it also doesn't fix the read status on those posts too.
-
I finally had a 1:1 meeting with my manager and kind of just laid it out.
Bulletpoints I gave:
- The process takes so long that I'm spending 10 times as much time doing paperwork than I am actually doing code
- The process doesn't work:
- The first code change I put through it, the tester was testing the wrong thing (because he didn't read the documents the process requires)
- The third-party vendor code we have is awful, and obviously was not within an order of magnitude the quality our process would impose on it<sup>*
- The work I'm doing could easily be done by a college grad at half my payscale. It's hard to bring up points like that without sounding like an egomaniac, so I just upfront said, "I'm going to sound like an egomaniac here, but..."
I didn't bring up anything about the lack of perks, crappy cube, crappy culture, etc. Also keep in mind that everybody's in a goddamned cube, even my manager, so you can't really have a truly private 1:1 meeting, so I had to temper a lot of what I would have said.
Anyway, he said the actual development project he'd hired me to cover hasn't really kicked off yet, and he'll check on its status-- it's actual real development work! But I wager it'll never kick-off until after my contract is up.
And he said he'd talk to our scrummaster-esque person to see if there are any more interesting, more development-oriented tasks to do. I know there aren't. Unless there are secret hidden tasks not in the backlog.
At least concern was expressed, I guess. I don't know.
* We had a little debate over this. I said with my own projects at least, the process was super-long and didn't seem to produce better results than previous companies I've worked at that had much simpler process. He replied, "well regulatory, customer confidence, yada". I replied, "right, I get that regulators and customers are concerned for their data, but we run the same data through this horrible third-party codebase which is a hundred times worse than anything we produce in-house."
-
Pro-tip: Wait for after the all-expenses-paid yacht club trip to raise hay.
-
I just got told my the scrum master-esque person that I've handled more backlog items in the last two sprints than anybody else. Even though I waste probably 66% of my time here waiting on blocking.
-
I just got told my the scrum master-esque person that I've handled more backlog items in the last two sprints than anybody else. Even though I waste probably 66% of my time here waiting on blocking.
That's TRWTF. Hire great people, compensate them well, give them a task and stay the fuck out of their way. That is how you get things done.
-
@Intercourse said:
That is how you get things done.
Given how many places don't do that, you could be forgiven for thinking they don't necessarily want things done.
-
I forgot to mention that they're bringing in a new developer next week. I could have the entire backlog "cleared" by next week, or maybe 2 weeks. I have no idea what this new person is going to be doing exactly.
BTW, in case you were wondering, "closing tickets" from the perspective of scrum just means getting them to "Ready to Test". We frequently have to wait a week or more for a QA resource to be assigned. So while I'm closing tickets, I'm not actually finishing anything.
-
I have no idea what this new person is going to be doing exactly.
Keeping you from finishing your projects, of course. Brooks' Law and all that.
-
We had the scrum call which was more of "The project managers want a chat to know if it is ready yet"
-
Makes me wonder how your workflow is set up. Our QA team is on a separate schedule. Definition of Done is completely realizable in a 2-week sprint:
- Implement
- Dev test
- Integration test (basically dev test, but by a different member of the team)
- Reference documentation
- Prepare user doc, send off to doc team who writes final version
- Run automated tests
- Create new automated test (if applicable)
- Merge to main
QA picks stuff up at some indeterminate point in the future and just files bugs for stuff they find.
-
Nah that would make too much sense.
Here we still have to babysit QA, which means just because I "finish" a project in sprint X, I'm still spending time babysitting it on sprint Y or Z. If we actually did have a huge workload, this would be a bitch to schedule.
-
Oh it is that type of Agile, where if there is a problem you get to look after it forever
-
BTW, in case you were wondering, "closing tickets" from the perspective of scrum just means getting them to "Ready to Test". We frequently have to wait a week or more for a QA resource to be assigned. So while I'm closing tickets, I'm not actually finishing anything.
Which is why scrum/agile just doesn't freaking work for slow-moving companies. It is probably worse than waterfall. You have to go all-in.
-
I personally don't think it works for any companies. Good companies pick bits that work (like daily stand-ups) and discard the crap that doesn't (like subdividing every single task into sub-4-hour chunks-- you spend more time subdividing and creating tickets than you would have to just write the damn thing!)
-
Or just go with kanban?
-
I've never been exposed to kanban.
-
I have always thought it was a better fit for large organizations.
What I always prefer to do is just break the scrum down in to reasonably manageable sections, but not necessarily worry about time on them. Just reasonable component chunks. The smallest sections that make sense.
A friend of mine works for an organization that always wants to break down scrum in to the smallest possible pieces. The extreme smallest segments, that could not possibly be broken down any further and his team lead thinks that is efficient. He spends more time moving boards between the swim lanes of the sprint than he does writing code. Whenever I see it, I always think that they may as well go ahead and write out pseudocode for their devs. It might even take less time.
-
-
Is it anything like kanjam?
No, but I saw that last night in a sporting goods store and my first thought was, "This was invented as a drinking game by someone in a park with nothing to work with by frisbees and trash cans."
-
@Intercourse said:
Or just go with kanban?
That's orthogonal to the other points made, and you can substitute with a decent issue tracker that supports a suitable state-graph model. The trick is to not worry too much about things that you're not currently working on.
The hard part is that all this is really best when you've got the basic structure of the system already defined. Architecture-level work doesn't fit nearly so well (though βfortunatelyβ a lot of software development never bothers with thinking about that and just bangs out the same old shit over and over).
Filed under: I'm not bitter
-
@Intercourse said:
A friend of mine works for an organization that always wants to break down scrum in to the smallest possible pieces. The extreme smallest segments, that could not possibly be broken down any further and his team lead thinks that is efficient. He spends more time moving boards between the swim lanes of the sprint than he does writing code.
If he thinks all that is a good idea, it's probably a good idea to keep him away from the code.
-
If he thinks all that is a good idea, it's probably a good idea to keep him away from the society and put him in a Unibomber shack in the mountains.
FTFY
-
regulators
I feel for you man.
Although (some) are better these days, I'll never forget, in my consulting days, being forced by a regulator to delete all host files from a client's desktops because "they let hackers in! (WTF!??!)" That promptly broke all the proprietary software they were running and effectively shut down the company. -_-
Next day, when he was gone, we put it all back and people were able to resume their work.
-
@Intercourse said:
Hire great people, compensate them well, give them a task and stay the fuck out of their way. That is how you get things done.
+1
-
It is probably worse than waterfall.
That's saying quite a bit, considering that Waterfall was never meant to work in the first place. Unfortunately, what seems to have happened is that a handful of half-witted CS professors read the first page of Royce's paper, got bored, then saw the big graphic on page two, and never got any further in it before saying, "wow, that looks really neat, I'll copy that and put it in my next textbook." And every moron in the industry copied them without realizing than not only was it a crock of shit, but that it was supposed to be a crock of shit. Sometimes I get the sneaking suspicion that I'm the only person in the past forty-three years to actually read the whole damn paper it came out of.
However, you're point is a valid one; while Agile's deliberate lack of planning works well for some types of projects, there are times you have to swallow the whole bowling ball. As I've said before, Agile is less a design approach as it is a response to the fact that we really don't know how to design software yet. It's a band-aid, and while band-aids are useful, using a whole lot of them to treat a punctured lung doesn't work.
Agile is mostly good for the same sorts of things OOP is good for: projects involving a lot of easily modularized, loosely coupled parts which are mostly similar to each other and need to be manipulated as units. It breaks down in the same sorts of places which OO does, too. In both cases, it was the rise of GUIs that really gave the spur to their adoption.
-
As we were taught, the point of scrum is to find something that works for your team, and not follow a predefined process.
The main downside still hanging around here is that you're not supposed to architect beyond the current BLI. I think it's short-sighted, but I seem to be alone in that opinion.
-
The main downside still hanging around here is that you're not supposed to architect beyond the current BLI. I think it's short-sighted, but I seem to be alone in that opinion.
Agile and Scrum work well for putting flesh on the skeleton that is the basic architecture. Getting the basic architecture right is rather harder, particularly because fixing it after the fact is viciously difficult.
-
Exactly. Luckily our management is susceptible to the argument "We won't touch X feature without giving it an architectural revision", as long as we don't overuse it.
And we've got a very good code review tool (usage mandatory).
-
Unfortunately, what seems to have happened is that a handful of half-witted CS professors read the first page of Royce's paper, got bored, then saw the big graphic on page two, and never got any further in it before saying, "wow, that looks really neat, I'll copy that and put it in my next textbook."
If only they had read one sentence further:
I believe in this concept, but the implementation described above is risky and invites failure.
-
If only they had read one sentence further:
>I believe in this concept, but the implementation described above is risky and invites failure.Yep. The problem is that a lot of projects don't know what they want up front, and often don't even know what they could want until after they've seen a mockup or first prototype. Waterfall is a model for where the development team can know up front what the exact overall goal is, but that's rare (it works in areas like avionics, railway signalling, chemical plant control systems, etc; these are usually very well described and safety critical).
Software engineering is an unusual engineering discipline in that the cost of going from prototype to production is unusually low, and the cost of fixing things in the field is also (mostly) unusually low. Almost everything else follows from those two basic facts; the rest of engineering tends to be very different precisely because those two steps are typically extremely expensive. Because it costs next to nothing to take a (good) prototype to production and fix it later, virtually all the costs of SE accrue from the creation of a series of prototypes of increasing sophistication, and the whole area can almost operate like a cottage industry. It's not, but the forces that drive the rest of engineering are either absent or dramatically lessened.
-
Sometimes I get the sneaking suspicion that I'm the only person in the past forty-three years to actually read the whole damn paper it came out of.
Well now we're two. The final process sketch seems actually sane and something that would produce good quality software for good quality money and time investment.If only they had read one sentence further:
They probably just believed even harder.I believe in this concept, but the implementation described above is risky and invites failure.
-
Yes. Royce's multi-iteration 'spiral' approach should have made that paper a seminal work in software design. Unfortunately, while it was indeed a seminal work in the field, it wasn't at all in the way Royce intended, and as a result the whole industry moved backwards rather than forwards.
-
Oddly, when I was introduced to project methodologies in school, we worked through the entire paper.
I didn't know it at the time, but seeing the paper, it corresponds basically 1:1 to the powerpoint slides that are burnt into my mind from the only important day in my entire university career.
And then we fucked off and did Agile.
In my day to day working life, we use the trappings of pure waterfall because the business understands it. In actual practice, we spiral. Because it happens naturally.
On super-large politically visible initiatives, we go to an ad-hoc agile model, but in order to prevent VP's from blowing gaskets we have an entire PM team devoted to translating it into a 'virtual' waterfall project. It's really fucking stupid.
-
Here's how my company does waterfall:
First we pick a deadline and communicate it to our external partners so we can't ever change it.
Then we halfass some requirements, mock up some screenshots, and hand it to developers.
The developers realize something's not clear. Clarifying it doubles the scope. The deadline doesn't change.
We poke at things for 2 hours, call it "tested" and ship it.
Our incident rate is too high. One of the directors starts blaming programmers for being "shitty at their jobs" and says "if they were doing their jobs right, we wouldn't have incidents".
The programmers cry.
-
My case:
- Managers ask programmers for deadline
- Programmers say 4 to 6 weeks
- 4 weeks later programmers realize they suck at deadlines
- Programmers work overtime and cry
-
On super-large politically visible initiatives, we go to an ad-hoc agile model, but in order to prevent VP's from blowing gaskets we have an entire PM team devoted to translating it into a 'virtual' waterfall project.
Just say that you're optimising the waterfall by putting some of the testing at the same time so all those expensive testers can be kept busy while the design and development are finished off. The one thing that VPs hate more than anything else tends to be costs blown in stupid ways, and optimising the use of the human resources assigned to the project is usually a Good Thing.
Unless you're working on certain kinds of projects, when the goal is to exactly spend the budget in the time allotted, and not a single nickel less.
-
First we pick a deadline and communicate it to our external partners so we can't ever change it.
Then we halfass some requirements, mock up some screenshots, and hand it to developers.
The developers realize something's not clear. Clarifying it doubles the scope. The deadline doesn't change.
We poke at things for 2 hours, call it "tested" and ship it.
This is about how we do it too, except the customers are internal and we communicate the whole year's deadlines at the start, and the size of a release wasn't based on how much we could actually do, just how much change the business asked for. We've just started actually sizing them properly based on the amount of resource we actually have.
Oh, and we can't move the deadlines out but those in charge will let them be moved in on the business' request even if we provide evidence that it won't work - and they can still ask for extra releases to be stuck in the gaps where we're supposed to be doing sensible things like warranty and other fixes which result in needing to do 4 months of work in 2 without any of the other work moving or being reduced.
-
In my case, planning and design alternates between my boss saying "We need a feature freeze. Let the application live for a while and see how it works." and "Mr GOG, how soon can you deliver feature X?" Being a development team of one, I find it easy to adapt - unless I'm suddenly called on to deal with the Client from Hell or to do someone's VAT.
It's a good job that the two apps I'm developing are for in-house use only and not business-critical.
-
-
Ah, you practice the waterfail modelβ¦
-
Oddly, I can honestly say that this group has literally never had a failed project. Hundreds of projects, zero failures. A lot of difficult berths, a few expensive ones, but it has always gotten done, and it always worked plus or minus some number of lingering ongoing bugs.
I mean that literally. Zero failures. Never more than a few days late no matter how absurd the deadline. A team of rockstar programmers with the most piss-poor management in the history of every. Some customers abandoned the project, but never because of IT concerns - it was always political, or manufacturing, or our business idiots not bothering to tell us about IT concerns that we could have addressed full stop.
{Vaguely related rant ON}
In our particular problem domain, there's only been one failure - and it was a project that we refused to do for manpower reasons and went to another part of the company. They failed. Hard. Spectacularly. Stock-price-shatteringly. And then the group responsible for the most monumental fuckup in company history picked up my team and we now have a jackwad VP parading around in front of other VP's, the board, etc. proclaiming to all comers that we were responsible (There's a lot of general confusion among the business about 'who is who' in our software development groups to the point that many share names, and many more are named after common domain tasks. My personal theory is that this is intentional.) and his new, enhanced team will pick up the pieces (and by that, he means "Weng and about a half dozen other heroic sons of bitches will personally save my career")
-
My case:
Managers ask programmers for deadline
Programmers say 4 to 6 weeks
4 weeks later programmers realize they suck at deadlines
Programmers work overtime and cryMost of the places I've worked:
- Managers tell programmers they have four weeks to meet deadline.
- Programmers take one look at the requirements and say "that's ridiculous, this is twelve weeks at best, and that's only if nobody decides to start adding requirements while we're underway".
- Managers nod and say they're in total agreement.
- Managers sneak off and tell customers they'll have it in four weeks.
- Four weeks later, managers come to programmers and say the customers want to know why the project is late, after all you told us we were in agreement.
- Programmers exercise superhuman restraint and do not kill and devour the managers on the spot.
-
You forgot the bit where they add new requirements in.
That comes on day 2, day 3, day 4, day 5, day 8 (day 6 and 7 were the weekend, when they were dreaming up new requirements but you guys were pretending that you were having some personal time), day 9, day 10, β¦
-
My case:
- Managers ask programmers for deadline
- Programmers say 4 to 6 weeks
- 4 weeks later programmers realize they suck at deadlines
- Programmers work overtime and cry
I know for a fact I suck at giving people time estimates.
-
I know for a fact I suck at giving people time estimates.
I've found that I'm pretty spot-on for small to medium job estimates where the client is up front with me.
As soon as you get those clients that have hidden problems, or those that like to "feature creep" you...all bets are off.
Side note: Best handling of "feature creep" I've seen: "Yes sir, we can certainly do that for you!" --Pulls out clipboard with Quote sheet.-- "Let's estimate the cost of that addition. What exactly did you say you wanted? Oh, it wasn't that important? Oh, ok. I understand perfectly sir. Thank you."
Filed under: Nice try.
-
As soon as you get those clients that have hidden problems, or those that like to "feature creep" you...all bets are off.
Best response I ever came up with for feature creep was to simply say "yes sir, we can do that for you. Now, it's ten weeks into what we all agreed was a twelve-week project, so we'll just set the clock back to zero and start those twelve weeks again from right now."
-
-
After my current small company made all staff redundant (aside from the receptionist and CEO & MD, who are the owners) - which in itself is mildly demoralising - I'm more inclined to say, yes, I am sure-as-shit working for a big company.
I've signed up with one of the larger companies here in South Africa. It is probably going to be shit. But shit is better than unemployment, and it pays well.
EDIT - also, fuck you discourse, can you not insert a response inline instead of scrolling to the very fucking end? So my post is
a) completely out of context unless you use that shitty "threaded conversation nav"
b) 7km down-thread.. and the fucking UI jumps to the bottom so I have to scroll back up 6.9km to get to where I was posting to read the rest.Really this "infinite scroll" is infinitely annoying.
-
Really this "infinite scroll" is infinitely annoying.
Yes, but....
@scudsucker said:so I have to scroll back up 6.9km to get to where I was posting to read the rest.
Can be solved with
@scudsucker said:that shitty "threaded conversation nav"
Your post will definitely be out of all context on mobile where that doesn't exist, though.
Filed under: Defending Discourse? Oh dear.... I'm definitely doing it wrong
