From: Kirby McCloy [email protected]
Subject: Concerns about SMERPS
The SMERPS project seems to be going down the wrong path. I thought our quarterly goal was for IT modernization.

The email carried no specific call to action. It barely had a point, and was little more than bad-natured griping. It also came from Kirby, the CTO. The email triggered a four-alarm underpants fire as every manager on the SMERPS project tried to guess what Kirby might possibly mean.

Someplace between the frenzied cries of, “Chris, did you see Kirby’s email? How do we reply?” someone had the bright idea that maybe this was just politics. Maybe Kirby just wanted to feel like he was part of the process, that his input was valued. They could just schedule a little sit-down, with Kirby, the PMs, and a few of the lead developers, and smooth this whole thing over.

Thus, Brittany found herself with an entire Friday afternoon blocked off for a meeting. None of the large conference rooms were available, which meant three PMs, the project coordinator, and four developers had to cram into a small office to review the plan. Thirty minutes into the meeting, they were all huddled around the projector for warmth, and the CTO was a no-show.

That didn’t dissuade management from trying to keep the meeting on track. “Well, while we wait for Kirby,” Chris said, “we can make sure we’re all on the same page. Let’s review the current plan.”

For the next two hours, the PMs nattered on about critical paths, resource leveling, and project milestones that were already unlikely to bear any resemblance to reality, and would only slip farther with each new bit of overmanagement. Brittany was nearly asleep when Chris called her name. “Why don’t you tell us about the technical side for the web team?”

“Well,” Brittany said, “SMERPS is a pretty straightforward CRUD app.” She noticed the vaguely surprised and offended look among some of the PMs and quickly explained, “Create-read-update-delete. A basic data-management tool.” The application needed to be accessible from the corporate office, at manufacturing sites, and at customer locations, and work on mobile devices. “All in all, it’s very similar to apps like RDR, TPM, and PlusPoint, so we’re planning to use the same tech-stack.”

Specifically, SQL Server for the database, C# for the backend services, and Angular2 and Typescript on the front-end. A good stretch of the project could be scaffolded out with automated tools, and most of the rest could be lifted from other projects. The hard parts- the 10% of the code that’d take 90% of the time to build- were the places where it needed to talk to the ERP system.

Brittany was in the process of making this explanation when Kirby swept into the room. “Sorry I’m late,” he said, “and I can’t stay long. But I have a few issues I’d like this team to address. First, there are a lot of resources on this project. I want you to be lean. There should be one developer on this project.”

“That’s impossible,” Brittany said.

The CTO rolled right over her. “It is if you’re using the right tools. Before this meeting, I did a little research, and did you know that Python is the number two programming language in the world? We’re going to use that for this project, which should make our developer more efficient.”

This statement was greeted with silence and a vaguely shell-shocked look. The CTO took this for agreement, rapped his knuckles on the table, and said. “Great. Good. Get on that. Email me with any questions. Now, if you’ll excuse me…”

John Cleese, dressed as a viking, in front of a picture of Spam; from the sketch show Monty Python's Flying Circus
What a Python might look like

As the door closed behind Kirby, Chris stepped up. “Okay, so you heard what the CTO suggested. Let’s not go making any big decisions just yet. Scott, Lisa, I need you to write up a clearer picture of the ERP side of the project, and why we need multiple ERP developers. Larry, Bob- you do the same for the web team. Brittany, before you leave for the day, I need you to do an alternatives analysis that compares our current tech with Python. Be objective and fair, but… well…”

“Well,” indeed. Brittany had no real opposition to Python as a language, but definitely did not like the idea of making a massive shift just on a CTO’s whims. She focused her analysis on a few key points. First, no one in their organization actually knew Python. Their entire portfolio was some flavor of .NET and the newer projects had added Angular. Their entire toolchain, build-process, continuous integration process, etc., all were built to support C# and Angular projects. Even beyond that, Python didn’t perform as well as C#, and since the requirements wanted a single-page application, they’d need to use Angular anyway, so there was no getting rid of Angular.

Brittany did her best to be thorough. That was easy. Being polite was harder. She was working late on Friday night to get the document over to Chris, who was also working late. When she hit send, he instantly replied to her with a big “THANKS!”. She went home, and ignored work until Monday.

On Monday, there was an email from Chris. “Got a meeting with Kirby at 11AM. Will follow up after.”

At 11:15, Brittany got an email from Kirby. “Saw your analysis,” he wrote, “but with 1 hour of research, I can disagree with it. Angular and TypeScript is old. Python is new, and Google is writing everything with it. Python is the best practices for development.”

The project was put on hold while everyone tried to talk some sense into Kirby. Kirby was adamant, though: he read that Google used Python, and so Initech also needed to use Python. “If our team still needs to use Angular, just use the Python version,” were his final words on the subject.

Brittany pulled Chris aside. “Chris, does Kirby even know what Python is? He clearly doesn’t know what Angular is. What happens if we just say, ‘Yes, we’ll use Python,’ and then… don’t?”

And that’s how Brittany completed her first major development project in Python, although it didn’t actually contain a single line of Python code.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!