Working in Development: Leaving sounds like a great decision.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.

«‹›2 »

Cancelbot: Nov 22, 2006; Canceling spam since 1928

More of a rant; Sometime in April we moved from "product" alignment to "project" alignment, despite the business being very much oriented around products; Call centre app, fulfilment, delivery management, stock, Front end website etc.

Teams - Before
- Back-end team had self-forming sub-teams depending on incoming requirements; Big delivery manager project V1.0 was built by delivery domain experts who lived in that team.
- Front-end team built the website, integrated with back-end team through services.
- Marketing do CMS things that integrate with website.

Team - Now
- Teams A through F, owned by a director who controls what projects go into the work stream as they call them.
- Any team can gently caress around in back-end/front-end and is encouraged to do so.

"You may encounter some problems transitioning", let's see:
- Teams now collide with each other; recently having 3 teams work in the same areas and severely loving with the release process.
- Each team has to know everything about everything, if not then its a painful learning process to work out the domain before even tackling the problem. Slowing poo poo down.
- Lack of domain specialism has reduced code quality as you won't be developing in that domain next sprint anyway, so nobody cares about long term any more.

Results; Productivity nosedived, lovely code quality, releases breaking everything, resentment between developers who once worked together and around 4 high profile resignations in the past month. But we must soldier on as we're still in the "forming" stage 8 months on and around 4 months behind.

I wouldn't recommend going to project alignment if your organisation has clear cut products.

Cancelbot fucked around with this message at 21:52 on Nov 30, 2015

# ¿ Nov 30, 2015 21:42

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 09:40

Cancelbot: Nov 22, 2006; Canceling spam since 1928

This is a good thing to watch (ignoring the "catchy" title); https://www.youtube.com/watch?v=a-BOSpxYJ9M

TL;DR - agile as a noun ruined everything, and:

quote:

Find out where you are
Take a small step towards your goal
Adjust your understanding based on what you learned
Repeat

If there is a choice, pick the option that makes it easier to change in the future

I'm getting tired of "2 week waterfall" :v:

# ¿ Feb 8, 2016 00:41

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Breaking the monolith - Salami style!

As a proof of concept for MICROSERVICES, a team broke out an address lookup from our big blob of a backend system. This has a post code entry, address fields, and a button to do lookups. Finally it updates the address on a customer order when you click a button.

They managed to break out 4 loving services for this nonsense, not including the existing postcode lookup via 3rd party!

- Postcode entry + results list service (Full vertical slice - Including markup!)
- Address entry service (Another full slice!)
- Address updater service which spoke to a "legacy connector"
- View aggregation service (take service output and combine into single view through jQuery HTML smashing)

All talking through an in-client javascript message bus, except the updater which eventually updated the database when something was pushed to rabbitMQ. I can see the point of making it a single service that takes in data / spits out data but 4 services, including one dedicated to smashing together two service outputs seems ridiculous to me?

# ¿ Jul 12, 2016 11:01

Cancelbot: Nov 22, 2006; Canceling spam since 1928

It's a fair point that they proved something. They wanted to see if they could break the monolith using microservices, by targeting a specific and common customer service task. The scale of the problem becomes evident in that each task is self contained in terms of user experience, but spiders out through a huge dependency tree that ultimately modifies a huge object in session. There are 28 such tasks, so you could naively extrapolate that around 80-90 services would be required to replace them all, including some shared services.

They did say they want a maximum of one hop out to keep the dependencies as light as possible, but I'm not sure how that works in practice because it's very easy to slide down the slippery slope of "one more dependency" that DI frameworks can lure you into.

My issue is that they are trying to solve the problem of being a big monolith means that it is a bad system, but replacing it with something that is conceptually identical, with the same constraints as when it was first built 8 years ago. Except this time it's lots of little services instead of lots of little classes. I see the benefit of microservices from a scaling and resiliency point of view, but I think that the problems are more nuanced than blob of code == bad.

Cancelbot fucked around with this message at 19:42 on Jul 14, 2016

# ¿ Jul 14, 2016 19:19

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Does anyone else think these "no estimates" events/fads/movements are targeted towards the wrong people? All the developers, QAs and analysts get invites and the talks seem tailored to them trying to push that idea upwards. But the business, projects, stakeholders etc. don't give a flying gently caress. I've seen developers push #NoEstimates and got told to gently caress off and give a proper estimate in the nicest possible terms.

But I work in a weird place whereby the business is supposed to treat us as a black box of requirements in -> software out, so in theory that poo poo should work because how we implement stuff is not their concern. Yet expectations and reality rarely get on.

# ¿ Aug 21, 2016 22:19

Cancelbot: Nov 22, 2006; Canceling spam since 1928

It's completely different in the UK, especially in the north west where good* developers are as rare as rocking horse poo poo. At least according to recruiters;

https://www.linkedin.com/pulse/war-digital-talent-north-west-ben-gledhill

This means salaries are shooting up like crazy, there's unreal amounts of developer churn as people are fighting for anyone who has uttered the phrase TDD.

* Good seems to mean good at the buzzword bingo and not a disruptive influence. gently caress graduates, people who may need some coaching, or the old.

# ¿ Sep 15, 2016 08:28

Cancelbot: Nov 22, 2006; Canceling spam since 1928

To contrast with PR chat, where I work is hard on the single branch approach:

- We use mercurial, everything goes into default
- Every commit must be releasable, if it is not you use a feature flag
- Nearly everybody pairs, we're experimenting with mobs

Does anyone else do this?

# ¿ Oct 4, 2016 21:37

Cancelbot: Nov 22, 2006; Canceling spam since 1928

vonnegutt posted:

I've done a little mob programming. I would say it is a huge waste of time 98% of the time. However, the 2% it was useful was when we were setting up a new project/framework. It was faster to just have the team lead do the main setup, routing, etc on a projector so that all the devs understand at least a bare bones version of where everything goes. You end up with a bit less churn at the beginning.

The one team that does it, the lead is super into it and won't allow poo poo to happen without the mob. When speaking to the other members they don't like it :v:

he also has a raging boner for "single piece flow/lean"

Every other team that tried it declared it pointless.

# ¿ Oct 5, 2016 18:14

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Miniature rant: What's the point of trying to push scrum/agile/lean through your software development process when the wider (and significantly larger) business don't even believe that poo poo. We could subordinate those bottlenecks and planning poker all loving day but you run into this poo poo:

:qq:

"What's the point of releasing something after 2 weeks, it won't be perfect!"

# ¿ Oct 13, 2016 08:56

Cancelbot: Nov 22, 2006; Canceling spam since 1928

toiletbrush posted:

Who are you delivering software for? ...

We are a .com selling household appliances, TVs etc. No physical stores at all so the whole business hinges on code and the development teams. I'm just coming out of a 6 month project whereby nothing was deliverable until right at the end, partly because we are poo poo devs who should have thought a few more steps ahead. But mostly because the business were very much "feature X can't go out until feature Y is 100% done", with sensible decision making we could have easily delivered incremental value and they could have easily cut losses, changed tack or evaluated performance at much earlier stages.

But its 6 months in, we're committed now!

Our head of development is actually awesome and will try to shield us from this poo poo, and encourage proper best practices. But the directors are a pain in the arse to deal with, to the point they can force crap like this through.

Cancelbot fucked around with this message at 13:30 on Oct 14, 2016

# ¿ Oct 14, 2016 13:21

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Sagacity posted:

And speaking of bol.com, I work there and we're always looking for talented people and can assist with your move to The Netherlands. For a fairly large company we have managed to avoid most agilefall traps (most...) and it's a friendly work atmosphere. PM for details

Why does your plaza API always break :argh:

# ¿ Jun 14, 2017 12:14

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Sagacity posted:

I'll have to plead ignorance about that. You're welcome to come and fix it?

It's one of the areas in the company that's in heavy flux and there are many conflicting requirements that the team is trying to unironically agilefall to success. Especially in the area of test automation they could use some help, I think.

Hah, we are a UK dev team with a tiny NL office. I'm sure we'd love to have a go but we have our own agilefall to contend with

# ¿ Jun 14, 2017 22:39

Cancelbot: Nov 22, 2006; Canceling spam since 1928

We are weighing up using an orchestration infrastructure as we just have several monoliths doing things that could be doing smaller, simpler things. Unfortunately we're 99% a Windows/.NET shop which doesn't quite fit inside containers and the dev culture is still all about throwing 30 services onto one box :v:

Nomad seems like a good fit as we can just do the shell execution path until things get split up better.

# ¿ Sep 14, 2017 08:14

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Vulture Culture posted:

Has anyone moved SRE/infrastructure teams to a 1-week sprint cadence? How did it work for you?

Me me! But only in the past month. We've also tried to get each ticket to 1 day and forcing ticket-splitting after 2 days as Infra stuff tends to inexplicably balloon as people pull at ever more tangled threads. I come from being a senior dev to being the "2nd" in our brand new SRE team so I've pulled a lot of practice from our team into this infra world.

So far it's working great, it makes things easier to measure and I think it'll eventually grind down "infra-creep" or at least make it easier to pick up and drop work without it being a catastrophe.

# ¿ Sep 22, 2017 21:56

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Disclosure: I'm the one in SRE (yay bullshit padding title) and I was originally a technical lead/senior developer, previously part of the teams that are now causing the poo poo.

On QA: I just had my meeting about load testing hijacked by a manager who wanted to treat any problem in our staging environment the same as a production issue. Essentially pinning these issues on Ops/SRE because his teams have been whining that the environment has been unstable.

poo poo developers did to cause problems
- Taking too many instances out of the load balancer; causing everything to fail health checks. This then prevents deployments from bringing instances back as there's no healthy state to recover to.
- Not transforming their configuration for the new QA environment, everything was in dev mode and pointing to to the wrong SQL instances and RabbitMQ virtual hosts.
- Not handling enough error states when saving customer data, meaning we had half saved JSON which needed manual intervention to recover. TWICE. Usually triggered by untested deploys.

poo poo Ops/SRE have done to cause problems
:confused:

I dunno, built the drat environment and only activated it when everything worked end to end.

But now SRE have been given the task of "self healing data" to paste over developer mistakes "Because its about reliability is it not?"

Cancelbot fucked around with this message at 21:32 on Nov 29, 2017

# ¿ Nov 29, 2017 21:26

Cancelbot: Nov 22, 2006; Canceling spam since 1928

This is the pre-live environment (staging), but we're just being blamed for developer cock ups because its new and SRE built it... not that they've been careless and ignored what we told them to do. I hate the "last person who touches it" game.

# ¿ Nov 29, 2017 21:49

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Pollyanna posted:

Then there�s what we�re doing, which is testing in-development code on live prod data, and encouraged to do so.

Aside from the data which we replicate and anonymise; I have no problems with that. I'm still a developer and all the crap comes out in staging as that's where your interaction points become more real. We can take real payments in staging and ship orders so it's ideal for checking for gently caress-ups without impacting customers. But what this manager wants is for something going wrong in a QA environment to be treated like the production environment, and I'm not doing a "P1 root cause analysis" for "poo poo worked in our mainline environment but promoting it broke". That's just the cycle of development which is always going to be faster than ops can keep up.

That is until the teams "embrace autonomy and the devops mentality", yeah, right after they learn how IIS bindings work :suicide:

# ¿ Nov 30, 2017 08:57

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Mniot posted:

Getting rage-flashbacks from this one.

Precisely! They'd commit stupid poo poo and because somehow prod was still working (because we block broken releases) they'd blame the environment for being broken, except no. You're pointing to a SQL database that only exists in your dev VM dummies!

# ¿ Dec 1, 2017 09:17

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Munkeymon posted:

I mean, it shouldn't be too hard to automatically rewrite connection strings in config files as part of deployment to prevent that specific sort of thing, I would hope.

It isn't!

web.environment.config is how it's done as we're a .NET shop. Our deployment pipeline will detect that and automatically apply an XML/JSON transform over them based on the deployment target, just their "staging" one was a cut & paste of the dev one with zero modifications. I'm pushing consul or at the very least environment variables as configuration so that I can remove that layer of silliness anyway.

# ¿ Dec 1, 2017 17:28

Cancelbot: Nov 22, 2006; Canceling spam since 1928

New Yorp New Yorp posted:

It's important to note that the default behavior in ASP .NET land is to apply the transform at build time based on the build configuration, which is awful. You want the transformation happening at deployment time, so you can reuse the same build through a pipeline of environments.

I feel as though I need to elaborate more, please take for granted that you may already know this but it's for the benefit of others in the thread:

We build everything in release mode using TeamCity with nothing transformed; we preserve the root web.config and every single web.environment.config gets bundled into a zipped artefact. The artefacts are then sent to Octopus deploy. Octopus will then select the correct file to transform the web.config based on the target environment and throw away the non matching transform files.

So;
- web.config
- web.beta.config
- web.staging.config
- all the other app files
Are all together in the MyApp.nupkg file.

1. Octopus will deploy to "beta" first, usually triggered by TeamCity
2. All app files are extracted to the target folder, on the target machine, in the target environment
3. web.beta.config will be applied to web.config via XSLT transformation, so everything that needs to change to work in beta has been changed on the real config.
4. Octopus then deletes all the non-matching transform files (in this case web.staging.config)
5. App is re-registered with load balancer

This is a fairly standard pipeline for .NET using TeamCity + Octopus, or so I thought? This has been working this way for years now. Until I created a new staging environment. They either didn't make a web.staging.config file, or made one that was copied from their dev files lazily and then I get blamed for everything breaking. Even though weeks before the project started all the teams were told to do these steps preemptively.

# ¿ Dec 1, 2017 20:12

Cancelbot: Nov 22, 2006; Canceling spam since 1928

So it finally happened: A live deployment failed as someone duplicated configuration which caused a duplicate key exception and took everything out for us. Easy SQL update and the team have applied a fix that will be promoted up.

3 hours later...

During testing of their fix, they ran the breaking SQL against production AGAIN thinking they were connected to test.

# ¿ Dec 4, 2017 19:35

Cancelbot: Nov 22, 2006; Canceling spam since 1928

I completely agree. There's just years of institutional crap I need to clean up where people just hop onto production SQL for "quick fixes".

# ¿ Dec 4, 2017 22:06

Cancelbot: Nov 22, 2006; Canceling spam since 1928

We have 5 different values which are repeated often and drilled into every recruitment pack. Plus the annual awards are based around these values. But in the end its still "make more money".

# ¿ Jan 18, 2018 22:13

Cancelbot: Nov 22, 2006; Canceling spam since 1928

You'll be fine! If its anything like my experience; your first couple days will be involving zero work and just learning the environment:

- Source control & where the code is
- Getting the project(s) up and running
- Where the servers are for the test environments, how poo poo is deployed
- Meeting team members, managers, etc.
- (Important) Learning where the tea/coffee/kitchen place is and how the microwaves work because nobody agrees on a standard UI

So relax into that and take each day a step at a time, your mind will be fried, and you will probably want to sleep as soon as you get home because of the sheer volume of information to take in. But it's all part of the process. I've been doing this for 11 years now and the first week at a new place still terrifies me.

# ¿ Jan 22, 2018 09:46

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Minor derail from question-questioning but I suspect some resignations over this one in our department:

"... As of this month we are going to be phasing out sugary drinks we provide, and replacing them with sugar free alternatives, with a view that from the beginning of April, we will only have no sugary drinks in the business. ..."

One developer is pretty much powered by his 4 can of coke a day habit. Sometimes he switches up and brings his own 3L bottles.

And also: Just ask questions, I get asked some pretty dumbass poo poo about stuff senior developers should know and still answer it anyway without passing judgement on the individual. Sometimes you have a brain fart and forget that unless you ToList() an IEnumerable in C# everything is in lazy-fairy-land and can screw up your unit tests, and other times I get asked some really challenging questions which cause me to ask the same question to people smarter than me, which to them might be obvious and dumbass-ey.

I think people are overthinking this way too much; I see question asking in IT the same way I imagine a fast food worker sees orders: They don't give a poo poo if you're ordering the quadruple stack, heart attack XL with 4 gallons of Pepsi or just a lean chicken salad, it's just part of the job that passes you by. I certainly don't think less of other developers when they ask questions. I judge them by other things; are they continually breaking production?, or not learning from their mistakes, or being a dick to people.

Cancelbot fucked around with this message at 09:29 on Jan 23, 2018

# ¿ Jan 23, 2018 09:26

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Munkeymon posted:

Probably for the best if you work with grown supposed adults who would ragequit a job that stopped stocking their preferred free candy.

Oh I agree, only one person complained in the end; and he was once suspended because he was playing Pokemon Go using an emulator on his dev machine. The rest of us are functioning adults.

# ¿ Jan 23, 2018 19:45

Cancelbot: Nov 22, 2006; Canceling spam since 1928

But we stock both Coke and KitKats, that's like double jeopardy right? They just appear in the fridges around the office each morning and developers being cuddly folk really enjoy them.

HardDiskD posted:

theres no ethical agilefall under capitalism

With kanban we can keep optimising for ethics!

# ¿ Jan 23, 2018 20:11

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Yeah they even exist in the UK: http://groceries.iceland.co.uk/coca-cola-classic-3l/p/13712 which is where I assume he's getting them.

# ¿ Jan 23, 2018 23:25

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Just to clear it up:

We have fridges dotted around the whole building with free chocolate, drinks etc. Which means there's also an ongoing joke about the <Company Name> stone (14lbs) of weight being gained in your first year. Additionally there is a tax being introduced in England where high sugar content drinks will cost more. So the joke + tax mean that the company has a good excuse to save some money but also be seen as healthier than they were.

All that's happening in reality to us;

Coke => Diet coke/coke zero
Fanta => Fanta zero
Some chocolate is now yoghurt and cereal bars

The department is growing by 60 people over 12 months and we're posting double digit revenue growth year on year. It'd help if we weren't also fat i suppose. But devs being devs some of them get loving triggered cos some sugar water is being replaced.

# ¿ Jan 24, 2018 23:22

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Hell yeah they do, but we get universal healthcare, 4-5 weeks of holidays, and relative to the rest of the economy we're paid incredibly well.

# ¿ Jan 24, 2018 23:46

Cancelbot: Nov 22, 2006; Canceling spam since 1928

meatbag posted:

Devs make decent money in Norway, I started on ~70 000 USD with no experience and two years education in coding.

Is that not also due to the tax system? My friend is a developer in Denmark and earns probably double what I do if we both converted to USD, but tax eats a more significant proportion of his salary (Paging Chamook) or the UK is just crap with salaries. 11 years in and i'm on $77,000 equivalent, with a review & promotion taking me to $86,000. It probably looks terrible compared to Norway, Germany, USA. But according to the IFS (https://www.ifs.org.uk/wheredoyoufitin/);

"you have a higher income than around 82% of the population - equivalent to about 52.0 million individuals."

Oh and I'm probably the highest paid developer in my org.

Cancelbot fucked around with this message at 09:51 on Jan 25, 2018

# ¿ Jan 25, 2018 09:35

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Ape Fist posted:

As my first week as a Jr Dev comes to a close I am comforted by the knowledge that everyone, including me, has no idea what the gently caress they're doing. Namaste.

One of us. One of us.

I hope you learned the important stuff: how and where is the caffeine is administered.

# ¿ Jan 25, 2018 19:35

Cancelbot: Nov 22, 2006; Canceling spam since 1928

I use full-fat Visual Studio for our C# stuff, VS Code is for everything else; Terraform, Packer, Ruby, Python, Go, Node, Powershell.

# ¿ Jan 26, 2018 20:30

Cancelbot: Nov 22, 2006; Canceling spam since 1928

B-Nasty posted:

It's the classic case of a free, useful tool becoming productized and extended to the degree where it now misses the original point.

That's the point at which I stopped using it too. I don't want to loving sign in or create an account to test some JSON - i know you can skip it but its a ridiculous bump in the road of Run Tool -> Test things.

# ¿ Jan 27, 2018 21:55

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Yeah at minimum "add" should be a method itself that deals with the logic of inserts internally to the object. If you need to expose the collection in some way (e.g. when you add and a UI has to show the new list) then make it a readonly collection on a getter.

code:

Foo.add(item)
Foo.getItems() // IEnumerable if you're C#, Iterable for Java

There's then more patterns after this, such as explicit Command/Query objects;

code:

FooRepository.add / update / delete
FooView.getAll / getById / getByParam

And the logical and insane conclusion is a purely functional representation where each insert copies the original object with the new item in the copy, leaving the original alone :v:

I once made a "functionally pure" shopping basket this way as part of the Potter Kata:

code:

public class Checkout
{
    private readonly IEnumerable<string> _items;
    private const decimal ItemPrice = 8m;

    public Checkout()
    {
        _items = Enumerable.Empty<string>();
    }

    private Checkout(IEnumerable<string> items)
    {
        _items = items;
    }

    public Checkout Scan(string item)
    {
        return new Checkout(_items.Concat(new List<string> {item}));
    }

    public decimal Total()
    {
        return _items.Count()*ItemPrice;
    }
}

[Test]
public void GivenTwoOfSameItemThenPriceIsDouble()
{
    var total = new Checkout()
        .Scan("HP1")
        .Scan("HP1")
        .Total();

    Assert.That(total, Is.EqualTo(16));
}

# ¿ Feb 2, 2018 09:33

Cancelbot: Nov 22, 2006; Canceling spam since 1928

gently caress open plan - Especially when the team behind you has a Bluetooth speaker, and instead of having a constant background level of music you can tune out; they will pick a random time and volume and just play some Hocus Pocus as their bipolar team lead is on a high note for that 5 minute period. This morning it was "Friday" by Rebecca Black. I don't even know what irony is anymore.

I'd be happy with per team offices at the minimum.

# ¿ Feb 15, 2018 09:48

Cancelbot: Nov 22, 2006; Canceling spam since 1928

I've had zero issues using git on our repositories; but we do treat it like mercurial and just merge everything with no history rewrites, squashing, and minimal rebasing. So we've never gone beyond the bare minimum to get stuff committed, pushed, etc.

Merge requests in GitLab is about as complicated as it gets.

# ¿ Oct 24, 2018 08:24

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Che Delilas posted:

Just read your code over and over and over again that works right?

https://www.teamten.com/lawrence/programming/dont-write-bugs.html

It's easy to not be ~~depressed~~ full of bugs, just ~~act happy~~ don't code bugs!

# ¿ Oct 28, 2018 18:33

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Right now our company is getting a hard on for value stream mapping, but I don't get why they are repeatedly trying to apply manufacturing principles to software engineering? I'm not saying software is un-plannable or the processes cannot be improved. But tickets/build artifacts/whatever isn't "inventory", we aren't building 10,000 widgets an hour. If they want to compare it to manufacturing; then it's a weird shop where every customer that comes in orders a very specific customisation every two weeks that only serve to make your widget ever larger as time goes on.

There's definite & clear processes where value stream mapping/lean manufacturing does fit; oddly enough it's the dumb easy-to-automate poo poo, but no we also have to do it as a one size fits all map that applies to stakeholder requests.

I've seen one teams value map and their prioritisation lead time is over 12 months because these things wildly vary based on stakeholder mood, current pressures, is it windy, etc. It is not a manufacturing process.

Cancelbot fucked around with this message at 13:22 on Jan 19, 2019

# ¿ Jan 19, 2019 13:19

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 09:40

Cancelbot: Nov 22, 2006; Canceling spam since 1928

the talent deficit posted:

i disagree completely that inventory is irrelevant to software development...

That's a fair enough point. I can see value in classifying things as inventory in order to identify the bottlenecks; the whole "ready for QA" rears its ugly head from time to time. I think I find a lot of my gripes about it come from management failings to grasp these issues or convey them in a way that actually applies to what is going on. "Do a value stream map!" without reasoning or being happy with ~12 month lead times from the backlog give the impression they're playing buzzword bingo rather than seeking out the root of these issues.

return0 posted:

I like to use some of that vocabulary (particularly inventory) to refer to work where the output the value delivered by the work is withheld until long after the work completes...

This is also a good read, and I'll take a look at the video posted by necrobobsledder.

bob dobbs is dead posted:

after years, i unironically believe that the only really great benchmark for whether you're doing grassroots agile is if the workers have seized materially the means of production and basically humiliated and emasculated the management

Cancelbot fucked around with this message at 15:36 on Jan 21, 2019

# ¿ Jan 21, 2019 15:34

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.

«‹›2 »