Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

qntm: Jun 17, 2009

evensevenone posted:

Agile is what you tell management you're doing so they don't try to hire PMs. That is the point of Agile. Everything else is to confuse upper management so they stop coming to your team meetings or asking when things will be finished.

Agile doesn't equate to "no PMs".

# ? Sep 27, 2015 12:28

Adbot: ADBOT LOVES YOU

# ? Jun 10, 2024 02:04

Soricidus: Oct 21, 2010; freedom-hating statist shill

sarehu posted:

Having to manage indentation up-front adds cognitive overhead when editing code -- something you might be unaware of if the cognitive overhead of capitalizing and punctuating your sentences is too high for you.

I only use languages that allow me to capitalise and punctuate my code properly. A nice tidy capital letter at the start of each statement makes everything else much more likely to be correct.

# ? Sep 27, 2015 13:25

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

evensevenone posted:

Agile is what you tell management you're doing so they don't try to hire PMs. That is the point of Agile. Everything else is to confuse upper management so they stop coming to your team meetings or asking when things will be finished.

I'd be like totally on board with that but what happens is, on a team basis:
1. The PM becomes the scrum master.
2. Some random rear end in a top hat becomes the product owner.
3. Another dude becomes the "technical lead."

Since scrummerfall doesn't work with huge numbers of people in a single scrum, mysteriously, other dysfunctional teams emerge, each with their own PM and SM and TLs. Then obviously you need a scrum of scrums leader and lead PO etc.

So in large teams, the number of people "leading" the project increases dramatically. Instead of one PM and one manager for a project with 4 teams of 7 people, you could easily have 5 scrum masters and 5 product owners, and these people don't write code. Bad agile has been a loving revolution for the PM industry, that's why they all have scrum certificates now.

# ? Sep 27, 2015 14:34

baquerd: Jul 2, 2007; by FactsAreUseless

Bruegels Fuckbooks posted:

So in large teams, the number of people "leading" the project increases dramatically. Instead of one PM and one manager for a project with 4 teams of 7 people, you could easily have 5 scrum masters and 5 product owners, and these people don't write code. Bad agile has been a loving revolution for the PM industry, that's why they all have scrum certificates now.

I've seen co-existing PMs (both product and project at the same time but different people), scrum masters, tech leads, product architects, system architects, resource managers, ISO certification, and product owners all in the same organization. It was pretty much 1:1 developers and "not developers".

# ? Sep 27, 2015 17:55

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

evensevenone posted:

Agile is what you tell management you're doing so they don't try to hire PMs. That is the point of Agile. Everything else is to confuse upper management so they stop coming to your team meetings or asking when things will be finished.

Lol, every "agile" environment I've worked in has had PM's.

# ? Sep 27, 2015 21:20

qntm: Jun 17, 2009

Agile isn't a magical software development methodology whereby somehow developers, just be being told how things are supposed to work, automatically fall into all of the correct procedures and don't need to be led anymore.

# ? Sep 27, 2015 23:16

Soricidus: Oct 21, 2010; freedom-hating statist shill

indeed, for we are all sinners and none can live up to the perfection that agile demands. but if we confess our failures to abide by the divine process, we may yet be forgiven and granted entry to the great standup in the sky, where there are neither bugs nor requirements nor users, but our velocity shall be infinite for ever and ever. in the name of the master and of the scrum and of the holy sprint, amen.

# ? Sep 28, 2015 00:21

Axiem: Oct 19, 2005; I want to leave my mind blank, but I'm terrified of what will happen if I do

If you are thinking of Agile as being or requiring a process, then I think you are doing it wrong. You all keep using words that have gotten attached to Agile, but aren't actually part of Agile themselves.

I think it is worthwhile on any so-called "Agile" project to go back and read the actual manifesto. It's available online: http://www.agilemanifesto.org

Agile is not about a one-size-fits-all approach. Agile is about empowering teams of people to determine what works best for them to continuously deliver software that meets the client's needs. Again: it is about empowering people, not strangling them.

This is not to say an Agile team cannot have processes or rituals--but the team chooses to adopt them or change them or whatever, in an attempt to be better at writing software. If the process is getting in the way of delivering software, then change (or drop) the process.

That Agile has suddenly become a buzzword that's infected industry to mean "a process that isn't waterfall but we're going to treat like it is" is one of the great tragedies of modern software development.

# ? Sep 28, 2015 03:24

tyrelhill: Jul 30, 2006

Maybe if something is so widely done wrong there is a problem with it?

# ? Sep 28, 2015 03:45

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Axiem posted:

If you are thinking of Agile as being or requiring a process, then I think you are doing it wrong. You all keep using words that have gotten attached to Agile, but aren't actually part of Agile themselves.

I think it is worthwhile on any so-called "Agile" project to go back and read the actual manifesto. It's available online: http://www.agilemanifesto.org

Agile is not about a one-size-fits-all approach. Agile is about empowering teams of people to determine what works best for them to continuously deliver software that meets the client's needs. Again: it is about empowering people, not strangling them.

This is not to say an Agile team cannot have processes or rituals--but the team chooses to adopt them or change them or whatever, in an attempt to be better at writing software. If the process is getting in the way of delivering software, then change (or drop) the process.

That Agile has suddenly become a buzzword that's infected industry to mean "a process that isn't waterfall but we're going to treat like it is" is one of the great tragedies of modern software development.

It hasn't been sudden at all.

Incidentally, how many people who have been introduced to agile software development have ever had any real buy-in to those points?

The manifesto says "people and interactions over processes and tools", and then you get introduced to agile by... the adoption [read: imposition] of a process like XP or Scrum or RUP (double-blurg).

"Working software over comprehensive documentation" isn't really unique to agile - it has been the rallying cry of people doing greenfield development since time immemorial, and the bane of people doing maintenance since the first software project was "finished" (hah!).

"Customer collaboration over contract negotiation" is great until the customer has to start cutting checks they didn't anticipate, and every methodology associated with agile has an overt or passive-aggressive mechanism for trying to bludgeon the customer into accepting that every change they want costs money and time - and generally these mechanisms just move the fight rather than preventing it, because the proximate problem is that the program's desired behavior is poorly specified and the fundamental problem is that the program's desired behavior is poorly understood and neither side wants to be on the hook for a process of indeterminate length and cost to figure it out.

Another question: at the time it came out, had any of the original signatories of the agile manifesto accomplished anything of note that would have lent them credibility? Looking at those names, I see a very high ratio of books published to successful software projects and a moderate ratio of books published to unsuccessful software projects.

# ? Sep 28, 2015 03:52

Zemyla: Aug 6, 2008; I'll take her off your hands. Pleasure doing business with you!

tyrelhill posted:

Maybe if something is so widely done wrong there is a problem with it?

There is a problem with software development in general.

# ? Sep 28, 2015 09:17

Carbon dioxide: Oct 9, 2012

Agile is the belief that you can run a marathon at a sprint, so long as you frequently stop and fire the starter's pistol again.

# ? Sep 28, 2015 10:12

I would blow Dane Cook: Dec 26, 2008

http://forums.somethingawful.com/showthread.php?threadid=3744073

I have just created the Agile Horrors thread so please take your hilarious tales of project management gone wrong there.

# ? Sep 28, 2015 10:51

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

Suspicious Dish posted:

Yeah. The more I work with timerfd, eventfd, signalfd (!!!), memfd, etc. the more I really love fd's becoming references to kernel objects. I only wish that userspace could create fd classes, although I don't want to open a whole round of bikeshedding with people saying I reinvented capabilities and microkernels

ioctl is also sort of poor, especially as it doesn't integrate well with seccomp. Hopefully they fix that.

My only wish is that everything supports *_CLOEXEC flags, so we don't have racy behavior out of the box.

The other problem is the per-process fd limit, but I think they're just going to make fd handling faster and raise that.

is this the first step to plan 9

# ? Sep 28, 2015 11:10

Blinkz0rz: May 27, 2001; MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

Carbon dioxide posted:

Agile is the belief that you can run a marathon at a sprint, so long as you frequently stop and fire the starter's pistol again.

# ? Sep 28, 2015 13:21

tyrelhill: Jul 30, 2006

Zemyla posted:

There is a problem with software development in general.

Yes the problem is surely software dev, not agile...

# ? Sep 28, 2015 14:16

Space Kablooey: May 6, 2009

Kanban is pretty good, though.

# ? Sep 28, 2015 14:24

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Malcolm XML posted:

is this the first step to plan 9

Nah plan 9 is the exact opposite of that and where we want to go

# ? Sep 28, 2015 15:47

substitute: Aug 30, 2003; you for my mum

All you gotta do is try...

code:

proto.update = function update(data){
	//trace("Menu: update");
	try{
	// Declare local variables.
	var menu;

	if(!data) return;

	// test menu type
	// and assign to data memeber
	switch(data.type){
		case Menu.TYPE_LIGHTBOX:
		try{this.menu=menu=GNS._lightbox;}
		catch(e){GNS._error("Menu: update > menu > lightbox: "+e);};
		break;

		case Menu.TYPE_OFFSCREEN:
		try{this.menu=menu=GNS._offscreennav;}
		catch(e){GNS._error("Menu: update > menu > offscreen: "+e);};
		break;

		default: return;
	}
	// update menu
	this.initMenuEvents();
	menu.update(data);
	}catch(e){GNS._error("Menu: update: "+e);};
};

# ? Sep 28, 2015 16:56

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Soricidus posted:

indeed, for we are all sinners and none can live up to the perfection that agile demands. but if we confess our failures to abide by the divine process, we may yet be forgiven and granted entry to the great standup in the sky, where there are neither bugs nor requirements nor users, but our velocity shall be infinite for ever and ever. in the name of the master and of the scrum and of the holy sprint, amen.

I might write this on a 'sad' post-it at the next sprint retrospective

# ? Sep 28, 2015 17:24

Presto: Nov 22, 2002; Keep calm and Harry on.

Ithaqua posted:

If I give an estimate and it sucks, it's my own drat fault. As someone with my head in the codebase, when I give an estimate, I'm at least likely to be in the right ballpark, not wildly high or wildly low.

At my last job, the main product was a couple million lines of code. Even with my head in the code base if you asked me how hard it would be to fix problem X I probably would have no idea. Might be one line of code or I might have to add a thousand lines scattered over 50 files. And none of the other devs would have any realistic idea either.

This is probably where someone will say "then you need to hire more people and break the project into smaller chunks!" Yep, and I would like a Lamborghini too.

# ? Sep 28, 2015 18:55

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Presto posted:

At my last job, the main product was a couple million lines of code. Even with my head in the code base if you asked me how hard it would be to fix problem X I probably would have no idea. Might be one line of code or I might have to add a thousand lines scattered over 50 files. And none of the other devs would have any realistic idea either.

This is probably where someone will say "then you need to hire more people and break the project into smaller chunks!" Yep, and I would like a Lamborghini too.

Then you give a high estimate, which indicates a higher degree of uncertainty. I worked on an application like that at one point. When management balked at the estimates for every PBI related to touching it being higher than they conceptually should have been, the rationale behind the high estimates was explained, and time was allocated for refactoring and reducing technical debt while also improving it in tangible ways. After a while, the code was in a better place and estimates were lower.

Things like that are contingent on having everyone in the organization on board with the process, of course. It's cool but depressingly uncommon to work for a place where the executives trust the developers and vice versa.

# ? Sep 28, 2015 19:02

JawnV6: Jul 4, 2004; So hot ...

Presto posted:

At my last job, the main product was a couple million lines of code. Even with my head in the code base if you asked me how hard it would be to fix problem X I probably would have no idea. Might be one line of code or I might have to add a thousand lines scattered over 50 files. And none of the other devs would have any realistic idea either.

This is probably where someone will say "then you need to hire more people and break the project into smaller chunks!" Yep, and I would like a Lamborghini too.

So what's your current process for determining the cost or time of a new feature? It's easy to say that you can't do agile, but if your state of the art is "Nobody knows how long anything takes ever" then the tension between sales and engineering isn't going to magically disappear on its own.

# ? Sep 28, 2015 19:14

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

Presto posted:

At my last job, the main product was a couple million lines of code. Even with my head in the code base if you asked me how hard it would be to fix problem X I probably would have no idea. Might be one line of code or I might have to add a thousand lines scattered over 50 files. And none of the other devs would have any realistic idea either.

This is probably where someone will say "then you need to hire more people and break the project into smaller chunks!" Yep, and I would like a Lamborghini too.

This is my situation. We have nearly 3000 developers and millions of lines of code. I can start on something simple-sounding (e.g., "Develop a summary report on x type of data") and 3 hours in be so neck-deep in old and convoluted infrastructure that this seemingly-simple task is now a multi-week adventure through code that is owned by another team that I can't touch.

# ? Sep 28, 2015 19:16

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

JawnV6 posted:

So what's your current process for determining the cost or time of a new feature? It's easy to say that you can't do agile, but if your state of the art is "Nobody knows how long anything takes ever" then the tension between sales and engineering isn't going to magically disappear on its own.

Schedule time to go and do the research, before deciding if it's worth doing the actual work. Even with more experts and the systems nicely decomposed, work often spans subsystems (and those subsystem contact points are the most fertile bug habitat), so saying "I'm gonna need a couple of days to come up with a good estimate" is often the right response.

# ? Sep 28, 2015 20:03

JawnV6: Jul 4, 2004; So hot ...

Subjunctive posted:

Schedule time to go and do the research, before deciding if it's worth doing the actual work. Even with more experts and the systems nicely decomposed, work often spans subsystems (and those subsystem contact points are the most fertile bug habitat), so saying "I'm gonna need a couple of days to come up with a good estimate" is often the right response.

As true as that is in the general case, I don't think that's applicable to the org above. I didn't get the impression a distinct effort estimate existed outside of "It's done and took X weeks." Sounded more like the go/no-go call is being made before an estimate collection process even takes place. But I might just be projecting my caricature of processless onto it.

I've seen people be really resistant to any hint of process and it's like translating from another culture. Granted, I have a lot of experience in an extremely process-centric development shop.

# ? Sep 28, 2015 20:22

Dirty Frank: Jul 8, 2004

LeftistMuslimObama posted:

... that I can't touch.

ok, that's impressive. I've given plenty of stupid high estimates when I know the code is a mess but actually not being able to touch the poop is new to me...

# ? Sep 28, 2015 21:17

carry on then: Jul 10, 2010; by VideoGames
(and can't post for 10 years!)

Dirty Frank posted:

ok, that's impressive. I've given plenty of stupid high estimates when I know the code is a mess but actually not being able to touch the poop is new to me...

On our larger product, each component is owned by a certain team and only those on the team have the authority in our (decrepitly old) source control system to actually commit. So if you want to actually make changes outside the purview of your own team you need to get the owner of that component to do it.

# ? Sep 28, 2015 21:38

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Sever.

# ? Sep 28, 2015 21:59

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

Dirty Frank posted:

ok, that's impressive. I've given plenty of stupid high estimates when I know the code is a mess but actually not being able to touch the poop is new to me...

Yeah, basically we're heavily integrated yet at the same time lots of the codebase is owned by lots of different teams and those teams have to sign off on changes to that code. They will basically never let an "outsider" touch their code lest you make changes that have consequences they'd need to follow up on.

This of course means that the only practical answers are either:
A) As soon as someone else's code that you're calling into doesn't work for you anymore without modifications, you're going to have to write your own code that does the same stuff
B) You have to run around getting a bunch of team leads and QAers and stuff from whichever team's code you want to mess with to sign off on your changes and agree to assign one of their own developers and QAers to do code review and testing on your changes.

We actually have a pretty good and rigorous testing and quality control process in place now, but a lot of this code is left over from the old days when we had no process and had a lot of fixation on integrating things that really didn't need it, resulting in the current mess.

I'm newer to the dev side of things and have been agitating for better process around changing other teams' code since the get-go, but cultural change is hard. We've at least, finally, moved away from the idea that a given project must ship in a particular version of the software and are now doing all our development in a way where projects only get merged in when they're actually done. Before it was like "scramble to get it done, ship a bunch of hotfixes after the fact".

# ? Sep 28, 2015 22:20

Linear Zoetrope: Nov 28, 2011; A hero must cook

A library I'm working with doesn't have any way to get an in-memory serialization of a model, so I just implemented serialization in Rust for my project using the following steps:

Get a name for a temp file
Pass the raw path for that temp file into the library so it can save there
Open that temp file and read it into a raw vector of bytes
Serialize the vector of bytes
Delete the file

Deserialization:

Decode these bytes
Create a temp file and raw dump the bytes into it
Tell the library to read in from that file
Delete the file

I am a terrible person. There is another way to do it where I could create a special "serializable" wrapper over the struct that takes a path as an argument and serializes into the path I'm given, then when deserialized attempts to read the model file from the decoded path, but I was using that for a while and it ended up being even more fragile (for one, it was difficult to send serialized models across OS's/dev environments, which this new monstrosity takes care of).

Linear Zoetrope fucked around with this message at 04:02 on Sep 29, 2015

# ? Sep 29, 2015 03:59

feedmegin: Jul 30, 2008

carry on then posted:

On our larger product, each component is owned by a certain team and only those on the team have the authority in our (decrepitly old) source control system to actually commit. So if you want to actually make changes outside the purview of your own team you need to get the owner of that component to do it.

That's fairly normal for a really large codebase, though? I mean, getting a change made shouldn't be a heavyweight process, but I would be annoyed if some random from halfway across the globe changed my team's code (and broke it on platforms X, Y and Z) without so much as a heads-up when attempting to fix it for his particular scenario on platform A.

# ? Sep 29, 2015 13:21

carry on then: Jul 10, 2010; by VideoGames
(and can't post for 10 years!)

feedmegin posted:

That's fairly normal for a really large codebase, though? I mean, getting a change made shouldn't be a heavyweight process, but I would be annoyed if some random from halfway across the globe changed my team's code (and broke it on platforms X, Y and Z) without so much as a heads-up when attempting to fix it for his particular scenario on platform A.

It doesn't sound as crazy to me as it seemed to some. Well, I guess I should finish that thought, because our smaller, shiny new offering in the same space does not follow that rule, and every component is open to everyone for delivery. It helps that the new product is maintained in a much nicer source control system as well, so it's easier to see when changes have been made to your component and what they might have broken. People have suggested on the mailing list to change the older to be like the newer, but that was met with quite a bit of apprehension. So I'm starting to wonder if it's more schools of thought than hard and fast rule.

# ? Sep 29, 2015 15:30

ToxicFrog: Apr 26, 2008

Here, anyone can submit changes to any component, but the change has to be reviewed (and approved) by one of the component owners. It strikes a nice balance between "it's easy to contribute to components you don't own" and "you can't just commit random stuff wherever", since you don't need to convince the owners to implement whatever you need right now, just to review your change that does that.

# ? Sep 29, 2015 15:38

ExcessBLarg!: Sep 1, 2001

carry on then posted:

It doesn't sound as crazy to me as it seemed to some.

It's quite common for large projects to be partitioned into modules that have different maintainers. You generally have commit access to the modules you maintain, but if you need to make changes elsewhere you'll have to submit those changes to a maintainer for review.

The problem is when you have an inflexible revision control system that doesn't allow you to share local changes among your teammates, while you're waiting for "upstream" to review and incorporate your changes.

ExcessBLarg! fucked around with this message at 16:30 on Sep 29, 2015

# ? Sep 29, 2015 16:27

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

ExcessBLarg! posted:

The problem is when you have an inflexible revision control system that doesn't allow you to share local changes among your teammates, while you're waiting for "upstream" to review and incorporate your changes.

And this is it right here. The DB/Server end of things for us is MUMPS. There is no true version control system for MUMPS. Instead we have cobbled together the best thing we can by having multiple development environments and doing "commits" by moving code to environments further along in the dev process. We also have some cobbled-together scripts that export the server code as text and commit it to an SVN repository, but it's just organized by commit date and instant and it's more of a "last resort" type of thing than true version control.

Because this is what we have to work with, teams are pretty defensive about their code because you can well and truly gently caress over a lot of people's work if you experiment in their code, as they're all developing in the same environment as you and if you break poo poo their stuff won't work. Or worse, you just make the code subtly wrong and it fucks up everyone else's testing in ways that takes forever to nail down.

I've never worked anywhere else as a developer, so I have no idea how other companies with millions of LOC handle source control for this sort of thing. We use SVN pretty successfully for our C# and VB6 code, but getting Cach� to play nicely with version control seems to be a lost cause.

Instead we do something like Develop in dev environment -> move code to code review environment and do code review -> move code to a testing environment and have QA do extensive testing -> repeat if code needs fixes, otherwise move it to the final environment from which we pack the software. It used to be that our environment structure didn't allow us to do that repeating step for broken code so we'd have to just start doing hotfixes instead. Now we can just keep baking things 'til they're done so it's not quite as horrific.

And to pre-empt everyone "Lol you use MUMPS that's the real horror". Yep, but we've had customers up and stable on this platform since the early 90s and it would introduce a ridiculous amount of instability to try to transition platforms just so we devs had a prettier language to work with. Why make work and difficulty for our customers when we're all perfectly good at programming in MUMPS and it only introduces a moderate level of difficulty over using a more modern database with some kind of ORM or whatever.

# ? Sep 29, 2015 16:46

Mr Shiny Pants: Nov 12, 2012

You work in health care right?

# ? Sep 29, 2015 17:22

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

Mr Shiny Pants posted:

You work in health care right?

Yep.

# ? Sep 29, 2015 17:24

lord of the files: Sep 4, 2012

not necessarily a "horror", but very accurate and incredibly, painfully true.

welcome to the arnoldJS, where all of your fears have come true: https://github.com/analytalica/ArnoldJS

# ? Sep 29, 2015 17:25

Adbot: ADBOT LOVES YOU

# ? Jun 10, 2024 02:04

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Needs a way to run it backwards to generate Ahnald dialog from source code IMO

# ? Sep 29, 2015 17:31

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »