Blog – Page 30 – The Renegade Coder

According to the internet's most reliable source, Wikipedia, the phrase "hurry up and wait" originated with the military in the 1940s. Today, that military mentality has infiltrated engineering culture as a project management strategy. But as usual, let's step back. In this article, I plan to tackle my personal misconceptions related to project management, and then I want to chat a bit about the harsh reality. As you can imagine, it's heavily related to the "hurry up and wait" mentality. Project Management Concepts In an ideal world, projects go through a thorough planning stage before pieces are delegated out to various teams. This planning stage allows management to determine how best to allocate their resources. Naturally, they're going to mess up at first. That's why we iterate. Iteration Iteration is the process of reviewing the current design and milestones for the following purposes: Identifying any roadblocks and redistributing workAdjusting scope to account for changes in requirementsPivoting as proof of concept designs failLocating bad interfaces and requesting rework In theory, iteration allows management to identify issues early and often. That way work is distributed fairly and is completed in a timely manner. Otherwise, you end up with a lot of frustrated employees. Many of the criticisms related to iteration involve documentation and scope. For starters, people often feel that iteration implies that nothing gets documented. More importantly, requirements never get documented. As a result, requirements slide around which causes a product to never be completed. The alternative is a more set-it-and-forget-it methodology like waterfall. Waterfall In waterfall, all the requirements are determined at the beginning, and the product is designed and implemented in a single cycle. If changes need to be made, an additional cycle or phase will occur. However, additional phases can only occur after releasing the product. That means failures are discovered after release and are addressed after another complete cycle. As pretty as it looks, you probably don't want to get close to it. In either case, it's up to management to fully utilize their resources. Otherwise, you end up with all the problems that engineers hate: downtime, rushing, duplicate work, bad interfaces, extraneous meetings, etc. Ain't nobody got time for that. The Hard Truth As always, I don't want to convey some stereotype that all engineers are bad. You have to keep in mind that my personality likely doesn't mesh well with corporate culture, so it's more my fault than the industry. However, that realization is not going to stop me from tearing apart my previous jobs. So, let's get into it! Greed Naturally, I expected engineering teams to excel at project management. After all, we love efficiency. And beyond that, we're just creators. Think of all the awesome things you get access to every day: cars, phones, computers, TVs, the internet, houses, bridges, etc. They're all engineering marvels. On the inside, however, engineering is an abomination. It's amazing some projects even make it out the door. In fact, I've actually seen the value of a human life used in an equation to justify why a particular failure was never mitigated. Yeah, so engineering has a bit of a greedy dark side. It just so happens that greed permeates the entire industry. In fact, it's part of the reason why management is so bad at looking out for their team. They value that next big raise over the livelihood of their own comrades. They really do piggyback off of engineering labor. It's a shame, but it's how corporate life operates. Overworked When greed isn't a factor, management still finds a way to mess things up. That's because they're typically too abstracted from the project to feasibly allocate resources. As a result, they're forced to rely upon previous allocations. Hell! If it ain't broke, don't fix it! As a result, you end up with nasty bottlenecks which cause some teams to work insane amounts of overtime to catch up to the rest of the group. Rather than redistributing the work and resources, the cycle continues. If you're part of the team that is overworked, you'll find that many of the senior engineers try to take on all the work alone. That's more of a stress induced reaction to the whole situation. It's easier to just take on the work than to train some junior engineers who might mess it up. In these situations, the younger engineers are stuck twiddling their thumbs as the team crumbles around them. Underworked Meanwhile if you happen to be on one of the teams that isn't buried in work, you'll find yourself spending a lot of time sitting around. This has nothing to do with being lazy or unmotivated. It's simply an indicator of how poorly projects are managed. That face when you don't have work to do, but you can't go home. Of course, redundancy doesn't exist in an engineering organization, so it's not even like you'd be equipped to help the other team out. You sort of just have to sit there and watch the other team fail to reach some arbitrary deadline. I say arbitrary because deadlines are almost always random. I mean what is a quarter anyways? How the hell does this random three-month period manage to drive the struggles of every engineer alive? Why do engineers even need to know what fiscal weeks are? When the work is done, it's done. If I sound like I'm ranting, just check out the urban dictionary definition for death march. Apparently, these arbitrary deadlines have their own eloquent term in the industry. At any rate, there's no way to create a schedule that will accelerate the completion of work. That requires proper resource management. "SCV Ready!" How it Plays Out You'll likely experience everything described above in your first few months as an engineer. If not, let me know. I want that job. If you're like me though, you're not having a good time. I've definitely seen both sides of it, and it often boils down to this military mentality. Probably the worst experience I had with this was in one of my most recent roles. The team didn't really follow any sort of process, so there were plenty of times where I would be sitting around waiting for work. At random, I would just get swamped with work that needed to be completed in a seemingly impossible timeline. Had there been any sort of planning, I could have been working away diligently to supply the team with a robust product. Instead, I found myself forced to commit terrible programming sins in the name of speed. It was dreadful, and I wouldn't wish that sort of job on anyone. My Manager, The Deadline Hero If you read my Miserable Management article, then you know which manager I'm talking about. This manager had absolutely no idea how to run a project, and it caused me a lot of pain and stress. To really put the following stories into perspective, I want to share some background about the role. When I joined the team, I was a prognostics engineer which is someone who writes predictive algorithms. Sound like a cool role? I thought so. When I joined, the team was made almost entirely of mechanical engineers who were dabbling in Python. In the year prior to joining the team, they managed to write two scripts that they were used to detect failures in the field. As a software engineer, it was my job to come and clean up this mess. In my first few months on the role, I introduced the team to productivity tools like GitHub, Confluence, and Jenkins. In addition, I reworked all of their code to be modular and easier to manage. That's a lot considering I was given two scripts filled with copy pasta, magic numbers, and cryptic comments. Tackling the Impossible Deadline So, where does this military mentality come in? I remember one of the worst times was when I was moving down to Atlanta. In the same weekend, I had planned to take the GRE. I wasn't really able to delay the move because I was also getting kicked out of my apartment, so it all had to happen at once. After that week, the 12-hour drive felt like nothing. Meanwhile at work, the same sort of scenario was occurring. My boss was going on a trip the following week, so he wanted all the deliverables in by Friday. Of course, some of these deliverables I found out about on Monday. This is like the epitome of "hurry up and wait." So what did I do? Well on Monday, I decided to get acquainted with the problem. I wasn't really sure of its priority since the email contained basically no context. In fact, I remember converting it to a GitHub issue and tagging it with help wanted. From that point on, I just went back to working on other minor issues. To be honest, I'm the type of person who's not going to bend over backwards in this kind of situation. People need to learn their lesson. They can't just drop stuff on me last-minute and expect it to get done. They need to see it fail, or they'll never learn. Unfortunately, if you've ever been in the business, then you know that my attitude never works. As a result, it sort of fell back on me by Tuesday. I was frantically trying to code up a solution without all the details. By Wednesday, I was forced out into the field for testing. I then spent the next 10 or so hours staring into a screen as others stared over my shoulder. It was miserable. Learning From Mistakes For reference, I was asked to complete a task which normally would have taken several months in just a week. This was NOT the first time either. In fact, our first formal release of the product required two tasks to be completed. One of those tasks took about 4 months while the other task was completed in a week. As you can probably imagine, the second task was garbage and required rework for several weeks after that. But, we had to get it out the door! Engineering is a joke. Fortunately, I felt like my manager was starting to learn from their mistakes. The reason I say that is because they were letting us sort of manage ourselves. As a result, my team started setting up realistic expectations. I remember at one point we ended up having a pretty major issue with that second task in the field, so one of my teammates decided to create a formal deadline for the next release. Our deadline was organized in two phases. The first deadline marked a code freeze, so we could spend time testing and fixing bugs before the second deadline. The second deadline was a hard release date. I loved it. Can't Teach an Old Manager New Tricks Unfortunately, both of those deadlines were short-lived. My manager ended up coming back from vacation and decided to push up both of our deadlines by a week. Now that wasn't the biggest deal in the world. We just had to cut a couple features and move on. The problem was my manager clearly misunderstood the point of a code freeze. Do plants add new features when they're frozen? No. We had to ship code on Friday. On Thursday, I received a text message from my manager that read: Let me know when you're free for a call... I was thinking about the failed comms... we need that fixed now - we don't want to be responsible for trashing an engine. Now I am all for their concern, but this was incredibly last-minute. This sort of text shows exactly how little knowledge they have of software. But even worse, this proves just how poorly they are at project management. Instead of taking responsibility and pushing back the deadline, they forced their problems onto me. Déjà Vu Oh, you thought it might be over by now? Nope. In that same day, I received a follow-up request: What else do you have to test/work right now? If you're waiting, can you work on how to handle failed Ethernet connections... I'm getting more nervous that we're going to have to fight through comm conflicts. At the time of my manager's request, part of that tool relied on an Ethernet connection to collect data. We had an attachment that would only run if that data met some conditions. If the Ethernet connection ever failed, the process would crash, and the attachment would shut down. I felt like that was perfectly acceptable behavior. Apparently, that behavior was suddenly not good enough for my manager. They wanted failed connections to resolve themselves magically as if a robot was going to just show up and reconnect the cable. Honestly, I have no idea what they were expecting. From Paper Airplanes to Jet Engines Naturally, I fired back with a bit of a rebuttal. I stated that this change would not be so simple and would likely require a restructure of the underlying framework. Their response: can you look at how I implemented previously? I think it was the infinite loop and just try to re-establish comms. Needless to say, I was more than a little pissed off. We're talking about a tool that had gone through several iterations since the prototype. Just for reference, we added a database, a logger, a user interface, a web service, and an installer utility. We were using GitHub, Confluence, Jenkins, and Artifactory. All of this complexity had been added since their little script, and they had the audacity to effectively say: "Well, I did it. It can't be that hard." That's like me turning around and saying: "I built a paper airplane once. What's so hard about jet engines?" But Wait, There's More! The thing that really kills me about that whole experience is that all three problems had the same root cause. The solution just required a little planning, but the military mentality got the best of my manager. That's the reality of engineering. We are forced to rush to get something done poorly only to sit around while it fails in the field. It's incredible. Fortunately for me, that manager ended up quitting their job. However, that didn't mean that his problems stopped haunting me. Two months after they left, one of their buddies messaged me about some code I had written 6 months prior. Keep in mind that this code got the stamp of approval from my old manager ages ago, but their friend never tried to run it. Apparently when they did, the code failed. This issue escalated because this person wanted the issue resolved immediately. Take some time to reread that sentence because it's the bane of every developers existence. Code is seen as magic to most people despite the intense concentration it requires. Sometimes I like to throw it back to people and make them fix it. After all, it's so easy. Anyway, I was forced to start working on it immediately. As I was grinding away, more and more people got involved until somebody starting throwing a fit that the software wasn't going through process. Next thing I know, we're pushing all my work out to be reviewed by the legal team. Talk about hurry up and wait. I'm so glad I got out of there. Reflection Believe it or not, the situations described above happened in just about every role I had. The only bit that was different was the team culture, so these situations were handled differently. In one of my previous roles, the hurry up part was always a bit too late. As a result, the team would be forced to put in insane shifts that resulted in downright dangerous code. Fortunately, I never really worked on anything mission critical, so we could get away with catastrophic failures without anyone getting hurt. However, that didn't mean the business didn't take a lot of heat. We did, and it only escalated the overall stress level. You'd think these events would have caused the team to address some of their project management issues, but I guess I was never that fortunate. Most teams were still using the waterfall methodology which is incompatible with software development. By no means is agile the key, but at least agile follows iteration. Waterfall sort of implies exactly what we've been talking about in this whole article. Problems come falling down faster and faster until they crash down. Guess who gets wet?