Thursday, April 24, 2014

A Tale of Two Methodologies

Today, I'm going to explain why working in IT is a goddamn nightmare by comparing two separate firms I've had the misfortune to work at. The first we'll call Company F and the second we'll call Company A.

Company F followed a simple but flexible development process. Customer submits a change request regarding the software. Analyst translates request into technical requirements and passes along to developer. Developer makes change and bounces it back to analyst for review. Analyst either accepts or rejects, and in case of the latter gives developer very specific reasons. All of this was tracked on a company webpage that could be filtered for release schedule, status, aspect of the project, etc.

The problems that came up had nothing to do with the process. First of all, the flagship software was shit on a brick. It was built by a single developer for ten years before he quit and they started passing it from one dev to another in a desperate attempt to keep building on the thousands of lines of spaghetti code. Any changes necessitated wholesale regression testing because even the simplest change could break functionality in some obscure corner of the software. Add to this the fact that all the developers at Company F were useless prima donnas who owed their job security to kissing the boss's ass - save for one - and it makes sense why I was such a regular in Arlington bars.

Now compare this to Company A, where the process is doomed from the start. Utilizing the management fad called Agile, requirements are called "stories" because it sounds different and creative. A story is pieced together at "storytime" where we unfortunately do not get cookies and milk - let alone a clear idea as to where this requirement came from and why it's necessary. Except for certain circumstances, which I'll be getting to in a moment. From storytime, the job goes into this website called Rally - a third-party project tracker that exclusively deals with Agile projects and which nobody actually doing work ever looks at. From there, it eventually gets brought into a "Sprint" which is a two week period focused on a set number of stories and thus makes it crunch time all the time. "Crunch Time" by the way is that period in a software development project where everything is due now! now! now! and is hated by every single IT worker ever.

A story, once in a sprint, can take one of two forms. Either it is committed and must be done within this two week period, or it is a "stretch" and can be done whenever. Theoretically we could work on nothing but stretch stories but then the technically illiterate middle management wouldn't be able to say "We committed to 10 points this sprint and completed 10 points! Checkout the size of my project management penis! It's all quantified and shit!' And then there's something called a "spike" which is "doing the research for a story we should have done before writing it up or assigning people to work on it."

And about those points - they don't matter. The team I'm on assigns values of 1, 2, 3, 5, or 8 to projects because nerds think using Fibonacci numbers make them the smartyest. In theory, these  numbers indicate man hours needed to complete the task. In practice, they indicate fuck all.

And different teams use different numbering conventions so how project managers are using them for their dick waving is another matter all together but has something to do with another Agile concept - "velocity." Basically if the team says "We will do X!" and then do X enough times, they have a high velocity and Polly Project Manager gets his cracker. If instead they do Y or Z... I really have no idea because everyone's velocity is all over the place and the project managers are still dug in like tumors.

As for daily story work, it is discussed every day at the same time in a "scrum." Agile evangelists insist it is not a status meeting but it is and they're stupid. Generally each person is working on a different story, or different subplots of the same story (which isn't an Agile term, thankfully) and if something that's committed looks like it won't get done now! now! now! then theoretically we can "swarm"on it. Because central to Agile methodology is the ideal that everyone on a team can do everything, like interchangeable cogs.

So that's what's wrong with Company A's process. And it gets worse because, as it's polluted with the faithful of Open Source, projects are done in a dozen different programming languages which makes any sort of reliable testing a nightmare. But they apply the same linear Programmer Think to the testing process - Step 1: Write Automation Test, Step 2: Run Automation Test, Step 3: Repeat. In theory, when these tests throw an error it indicates something that needs to be fixed. In practice, the emphasis is on creating tests and creating more tests and never doing any followup whatsoever.

Automated testing is useful and I wish it had existed at Company F, but there's no real point if no one ever regularly checks the results. Most of these tests fail every day and it's shrugged off as either "known bug" or "not my problem." Because no single dev has ownership of any of Company A's dozens of products and projects. That's one thing even the Company F devs got right - at least one of them took enough of a personal interest in some program or web application - or were assigned to do so - that analysts knew who to contact when something looked screwy. Company A has a third party bug tracker. And most of the bugs documented were found through manual testing. Or by customers. And still don't get addressed unless someone, somewhere, writes a story about them. Like "It was a dark and stormy night and my code is shit because I care more about posturing on Linux forums than I do about making a functional product."

Finally, there's training and documentation. Company F, for all its awfulness, did this really well. Everything was documented, if you didn't document you got a stern talking to, and all the documentation was both clear and easily accessible. Training, at least for analysts, was an in-depth one on one mentoring process that lasted the first full month on the job.

Training at Company A consists of either a "ramp up" story - which I never got - or training classes that address broad subjects and don't nearly prepare you for the actual work. They can't because every project has a team with its own "Best Practices" for doing things. This is all Agile's fault as it plays to the hippie-libertarian delusions of most programmers - "Everybody gets to do their own thing because freedom and free software and free porn at Pirate Bay!" And these Best Practices are documented on an equally ad hoc basis, if at all. The company wiki is bloated with information so out of date it references teams and projects that don't exist anymore! Actual Best Practices are more often than not team customs, which you can't possibly learn unless someone tells you. This isn't just sloppy and inefficient, it's how massive data fuck-ups happen.

This dysfunction isn't inherent to IT. Like I said, even Company F did some things right and a sysadmin who sits next to me doesn't buy into all the buzzword bullshit. And he's forever pulling his hair out, trying to maintain a server architecture that's been cobbled together by a dozen Open Source and Agile cultists. Who can't be contacted because no ownership and everyone moves between teams all the time, meaning we're constantly playing catch up and repeating work we didn't know already existed.

So that's why I'm pissed off all the time.

No comments:

Post a Comment