Last minute geek

last minute tech news from around the net

You are here: English WTF

WTF

Micro(managed)-services

Alan worked for Maria in the Books-and-Records department of a massive conglomerate. Her team was responsible for keeping all the historical customer transaction records on line and accessible for auditors and regulatory inquiries. There was a ginormous quantity of records of varying sizes in countless tables, going back decades.

Maria was constantly bombarded with performance issues caused by auditors issuing queries without PK fields, or even where-clauses. Naturally, these would bring the servers to their proverbial knees and essentially prevent anyone else from doing any work.

The Red Queen with Alice, from the original illustrations of 'Through the Looking Glass'

To solve this problem, Maria decided that all auditors and regulators would be locked out of the database for purposes of direct queries. Instead, they would be provided with an API that would allow them to mimic a where-clause. The underlying code would check to see if no PKs were specified, or if a where clause was missing altogether. If so, it would run the query at a much lower priority and the auditor issuing the offending query would wait while the servers did the massive scans in the background, so the other auditors could continue working with a reasonably responsive database.

So far, so good.

Alan wanted to build a mechanism to query the list of available tables, and the columns available in each. This could be provided via the API, which the auditors' developers could then programmatically use to create the objectified where-clause to submit as part of a query.

Maria would have nothing to do with that. Instead, she wanted to sit with each potential auditor and have them define every single query that they could possibly ever need (table(s), column(s), join(s), etc). Alan pointed out that the auditors could not possibly know this in advance until some issue arose and they had to find the data relevant to the issue. Since this would vary by issue, the queries would be different every time. As such, there was no way to hard-wire them into the API.

She put her foot down and demanded a specific list of queries since that was the only way to build an API.

Alan went to every auditor and asked for a list of all the queries they had issued in the past year. They grudgingly obliged.

Maria then went on to design each API function call with specific arguments required to execute the given underlying query. The results would then be returned in a dedicated POJO.

Again, Alan groaned that defining a POJO for each and every subset of columns was inappropriate; they should at least design the POJOs to handle the entire column set of the given table, and have getters that represented columns that were not requested as part of a given API query throw a column-not-queried exception. Maria said No and insisted on separate POJOs for each query.

Some time later, Alan had finished building the API. Once it was tested and deployed, the other development teams built relevant GUIs to use it and allow the auditors to pick the desired query and appropriate parameters to pass to it.

This worked well until an auditor needed to add a column to one of the queries. If Maria had let Alan use table-wide column pick-lists and POJOs that had all the fields of a table, this would have been easy. However, she didn't, and made him create another virtually identical API function, but with a parameter for the additional column.

Then it happened with another query. And another. And another.

After a while, there were so many versions of the API that the managers of the other teams blasted her choice of implementation (they had to deal with the different versions of the POJOs for each table in their code too) and demanded that it be made sane.

Finally, under pressure from above, Maria relented and instructed Alan to change the API to use the pick lists and POJOs he had originally wanted to provide.

To implement this required changing the signature of every method in the API. Fearing a riot from his counterparts, he got them all together and offered a two month window during which both old and new versions of the method calls would be supported. This would give their teams a chance to make the code changes without forcing them to drop their current priorities. The other developers and managers quickly agreed to the dual-mode window and thanked Alan.

Then a few of the other managers made the mistake of thanking Maria for the window in which to make changes.

She royally reamed Alan: "Did I tell you to give them a dual-mode window? Did I? You will immediately pull the old methods from the API and re-deploy. You will NOT email the other teams about this. Get it done; NOW!"

Alan had worked very hard to develop a good working relationship with his peers and their respective managers. Now he had been ordered to do something that was downright nasty and would absolutely destroy said relationships.

Alan changed the API, ran the tests, and entered the command to deploy it, but did not hit ENTER.

Then he quietly went around to each of the other managers, told them what he had been instructed to do and apologized for what was about to happen. He was somewhat taken aback when every single one of them told him not to worry; they had dealt with Maria before, that they appreciated his well-intentioned but ill-fated attempt to be a team player, and that they completely understood.

After that, he went back to his desk, hit ENTER, and contemplated asking the other managers if they could use a good developer.

[Advertisement] Manage IT infrastructure as code across all environments with Puppet. Puppet Enterprise now offers more control and insight, with role-based access control, activity logging and all-new Puppet Apps. Start your free trial today!

Read all

CodeSOD: Dictionary Definition of a Loop

Ah, the grand old Dictionary/Map structure. It’s so useful, languages like Python secretly implement most of their objects using it, and JavaScript objects imitate it. One of its powers is that it allows you to create a sparse array, indexed by any data type you want to index it by.

Catherine’s cow-orker certainly thought this was pretty great, so they went ahead on and used the Dictionary to map interest rates to years. Years, for this application, were not tracked as actual years, but relative to an agreed upon “year zero”- the first year of the company’s operation. There was a new annual interest rate tracked for each year since.

If you’re saying to yourself, “wait… this sounds like a use case for arrays…”, you’re onto something. Pity you didn’t work with Catherine. You probably wouldn’t have left this behind:

private static double FindInterestRate(int operationYear, Dictionary<int, double> yearToInterestRates) //where 0 is the first year
{
    if (operationYear < 0)
        return 0;
    else
    {
        for(int i = 1; i < yearToInterestRates.Count; i++)
        {
            if (operationYear < yearToInterestRates.ElementAt(i).Key - 1)
                return yearToInterestRates.ElementAt(i - 1).Value;
        }
        return yearToInterestRates.Last().Value;
    }
}

Now, even if you don’t know C#, this is obviously pretty bad, but it’s actually worse than you think. Let’s talk for a minute about the ElementAt method. Accessing a key in a dictionary is an O(1) operation, but that’s not what ElementAt does. ElementAt finds elements by indexes, essentially treating this Dictionary like an array. And how does ElementAt actually find elements in a non-linear structure? By iterating, meaning ElementAt is an O(n) operation, making this loop O(n2).

Remember, our goal, is to find a specific index in an array. Compare the efficiency.

[Advertisement] Universal Package Manager – store all your Maven, NuGet, Chocolatey, npm, Bower, TFS, TeamCity, Jenkins packages in one central location. Learn more today!

Read all

Tales from the Interview: That Lying First Impression

Pickup truck with spoilers

Dima had just finished her Masters in electrical engineering, and was eagerly seeking out a job. She didn't feel any particular need to stick close to her alma mater, so she'd been applying to jobs all over the country.

When the phone rang during lunch hour, she was excited to learn it was a recruiter. After confirming he had the right person on the phone, he got right down to business: "We saw your resume this morning, and we're very impressed. We'd like you to come out for an on-site interview and tour. What's your availability next week?"

Dima agreed. It was only after she hung up that she realized he'd never given his name or company. Thankfully, he sent her an email within ten minutes with the information. It seemed he was representing DefCo, a major defense contractor with the US government. This would normally be worth a look; it was particularly interesting, however, because she'd only submitted her resume about an hour and a half prior.

They must be really impressed, she thought as she replied to confirm the travel arrangements. It'll be nice working someplace large that doesn't take forever to get things done.

A week later, Dima hopped out of the cab and made her way into the building. Wrinkle number one immediately presented itself: there were at least twenty other people standing around looking nervous and holding resumes.

I guess they interview in groups? she wondered. Well, they're clearly efficient.

As Dima waited to tour her first top-secret manufacturing plant, she made small talk with some of the other candidates, and hit wrinkle number two: they weren't all here for the same job. Several were business majors, others had only a high school diploma, while others were mathematicians and liberal arts majors.

Clearly they're consolidating the tour. Then we'll split up for interviews ...?

The tour guide, a reedy man with a nervous demeanor and a soft, timid voice, informed them that interviews would be conducted later in the day, after the tour. He walked them down the hallway.

Dima kept close to near the front so she could hear what he was saying. She needn't have bothered. As they passed the first closed door, he gestured to it and stammered out, "This might be a lab, I think? It could be one of the engineering labs, or perhaps one of the test facilities. They might even be writing software behind there. It's bound to be something exciting."

This went on for the better part of two hours. They passed locked door after locked door, with their guide only speculating on what might be inside as he fidgeted with his glasses and avoided eye contact. Finally, he declared, "And now, we'll tour the test facilities. Right this way to the warehouse, please. You're going to love this."

Wait, he didn't hedge his bets? We might actually see something today?! Dima knew better than to get her hopes up, but she couldn't help it. It wasn't as though they could get any lower.

They were let into the warehouse, and their guide took them straight toward one particular corner. As they crowded around what appeared to be an ordinary truck, their guide explained its significance in hushed, breath-taken tones: "This is the system upon which our new top-secret mobile Smart-SAM and cross-pulsed radar will be mounted. Soon, this will be one of the most advanced mobile platforms in the United States!"

And soon, it will be exciting, thought Dima in dismay. Right now, it's a truck.

"This concludes our tour," announced the guide, and it was all Dima could do not to groan. At least the interview is next. That can't be nearly as much of a let-down as the tour.

Dima was shown to a waiting area with the mathematician, while the others were spilt into their own separate areas. She was called back for her interview moments later. At least they're still punctual?

The interviewer introduced himself, and they shook hands. "Have you ever worked on a power supply, Dima?" he asked, which seemed like a logical question to begin the interview. She was just about to answer when he continued, "Just last week I was working on the supply for our cross-pulsed radar. That thing is huge, you wouldn't even believe it. Of course, it's not the biggest one I've ever built. Let's see now, that would've been back in '84 ..."

To her horror, he continued in this vein for fifteen minutes, discussing all the large power supplies he'd worked on. For the last five minutes of the interview he changed topics, discussing sound amplifiers you could run off those power supplies, and then which bands would make best use of them (Aerosmith? Metallica? Dima didn't care. She just kept nodding, no longer bothering to even smile). Finally, he thanked her for her time, and sent her on her way.

The next day, Dima was informed that she hadn't obtained the position. She breathed a sigh of relief and went on with her search.

[Advertisement] Manage IT infrastructure as code across all environments with Puppet. Puppet Enterprise now offers more control and insight, with role-based access control, activity logging and all-new Puppet Apps. Start your free trial today!

Read all

CodeSOD: Countup Timer

Dan has inherited a pile of Objective-C. That’s not the WTF. The previous developer had some… creative problem solving techniques.

For example, he needed to show a splash screen, and after three seconds, make it vanish. You might be thinking to yourself, “So I set a timer for 3000 milliseconds, and then close the splash screen, right?”

- (void)viewDidLoad {
    [super viewDidLoad];
    count=0;
    timerSplashScreen = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(StartLoading) userInfo:nil repeats:YES];
}

-(void)StartLoading {
    if(count==3){
        [timerSplashScreen invalidate];
        // Close the splash screen
    }
    count++;
}

Of course not! You set a timer for 1 second, and then count how many times the timer has fired. When the count hits 3, you can close the splash screen. Oh, for bonus points, increment the count after checking the count, so that way you have a lovely off-by-one bug that means the splash screen stays up for 4 seconds, not 3.

[Advertisement] Onsite, remote, bare-metal or cloud – create, configure and orchestrate 1,000s of servers, all from the same dashboard while continually monitoring for drift and allowing for instantaneous remediation. Download Otter today!

Read all

Error'd: Nothing to Lose

"With fraud protection like this, I feel very safe using my card everywhere," Brad W. writes.

 

"Well if so many other people are buying them - they must be good right?" writes Andy H.

 

David A. wrote, "Attempting to use the Asus WinFlash utility to update the BIOS on my Asus laptop left me confused and in doubt."

 

Mathias S. wrote, "You know, I think I'll just play it safe and just go with 'Show notifications for '%1!u! minutes'"

 

"To me, seeing three overlaid spinners suggests you'll be waiting for a while," writes Daniel C.

 

Quentin G. wrote, "If only this was the first one of these that wasn't supposed to show up I wouldn't have submitted it, but crap, after the third one in a row they deserve to be shamed."

 

"Ok, so the error is pretty obvious, but what gets me is that while they couldn't be bothered to fix the actual bug, but cared enough to put up that warning," writes Jamie.

 

[Advertisement] Manage IT infrastructure as code across all environments with Puppet. Puppet Enterprise now offers more control and insight, with role-based access control, activity logging and all-new Puppet Apps. Start your free trial today!

Read all

Software on the Rocks: Episode 4: Anarchy for Sale

Thanks to a combination of illnesses, travel, timezones, and the other horrors of the modern world, we took a week off. If Angular can skip version 3, we can skip episode 3. Welcome to Episode 4 of Software on the Rocks, brought to you by Atalasoft.

In today’s episode, we are joined by TDWTF author Jane Bailey. We talk about the process of writing, the nature of programming, and “programmer anarchy”.

This episode of Software on the Rocks is brought to you by Atalasoft.


MP3

Web Player



We’ll be back in two weeks, when Alex and Remy finally have a duel to the death. Two programmers enter, only one programmer leaves. Follow future episodes here on the site, or subscribe to our podcast.

Transcript

Alex: So, I guess this is episode number three now, if I’m keeping track, right?

Remy: So, that makes three episodes that you’ve started by saying, “So, I guess this is…”

Alex: Oh, look. We’ve got – I don’t know. We’re not doing these right after another. Podcasting is pretty new to me, and I don’t know. I think this is a lot of fun. I’m enjoying it. And from what I can tell from reading the comments, the readers are absolutely enjoying it, too. Remy, I want to read this one to you. It’s from Ross, and then in parentheses, “unregistered.” So, let me read you his comment, because it, I really think, speaks to the heart of what we’re doing here. [Clears throat] Okay. “Not that anybody at The Daily WTF will care, but I, too, have no f---ing interest in The Daily WTF podcast, or any other podcast whatsoever. I won’t listen. I won’t read the transcripts. I’m hoping that you continue putting ‘Software on the Rocks’ in the title so I can get my RSS feed to ignore them.” Eh? That’s exciting, yeah?

Jane: Sounds about right. Yeah, that’s what we hope to hear. [ Chuckles ]

Alex: Here’s another commenter that says, “This is just terrible and an absolute waste of time.” They won’t come back, and it’s sad that they won’t hear me thanking them for sharing all of this great feedback to them, but, nonetheless, I’m happy that they listened to at least our first two episodes.

Remy: Hello, everyone. Let’s actually do our introductions. I’m Remy with Alex Papadimoulis, and we also have, today, Jane, who you may know as Bailey from The Daily WTF. She’s one of the writers, contributes a lot of great articles, so I wanted to introduce her and give her a chance to say hello.

Jane: Remy, I am always having fun, but now more so than ever.

Remy: Bailey actually joined the site – It’s a couple of years ago now – shortly after I took on as being chief editor. But as part of me single-handedly ruining the site, I brought in a bunch of people who hadn’t written for the site before and said, “Start writing for the site,” and Jane was one of those folks.

Alex: I think it’s great. The commenters, again – They also seem to just hate it. But they’ve f---ing hated everything ever since day two of the website; so still, we’re on that continued decline from our height. I didn’t really think that Daily WTF would ever evolve into this sort of – I guess you could call it – what? – I.T. fiction? Or I guess you could call it I.T. based on true stories. But it’s really interesting to read, and it’s a fun blend between sort of our day jobs and fiction that captivates and tells stories.

Remy: I don’t know about you, Jane. I have a very specific process I use for turning a submission into a story. Our readers often accuse us of fictionalizing too much or anonymizing too hard. I don’t know about you personally. I actually don’t do very much of that at all. Personally, if I’m fictionalizing, it’s because the submission itself didn’t contain a lot of details, and the details I add are almost always from, like, real-world experiences I’ve had.

Jane: Yeah, I absolutely agree. Sometimes they’re details of coworkers I’ve spoken with, telling me their horror stories, or other things that I’ve seen around The Daily WTF forums, but more often than not, they’re just things that I have seen, you know?

Alex: You know, certainly a lot of folks have written in or have commented and said, “Oh, this is clearly a fabricated story,” or “clearly, you’ve made up a lot of the details.” But, you know, what I think is more accurate, or certainly worth considering, at least, is the folks telling these stories are the ones who have forgotten almost all of the details. Every time you retell that story to your friends, to your coworkers, to whomever, the story gets more and more muddled. So, the reality of what actually happened is really vague to begin with, and if we were to break down those – the bits of the story that they actually share, it would be really boring and certainly no one would be reading it. One of the best bits of feedback that I’ve ever received was from a guy that I met who had sent in a story. He said that “You changed every detail in the story for the most part; however, after I read it, it felt more like that’s exactly what happened than in my own mind.” And that, to me, was a good way to sort of recreate an event in a fictional sense.

Remy: I kind of always think of it more like, back in the ‘50s and ‘60s, you had the “true crime” writers, right? And they would take real-world news stories – you know, murders and gang killings – and they would turn them into these novels that had a lot of fictionalized details. They certainly played up the more salacious elements of the whole thing. But their goal there was to take something that was based in reality, decorate into something that was also entertaining.

Jane: I think some of my favorite submissions are ones where the submitter has clearly not understood what was the most interesting part of the story or possibly is completely in the wrong about what was happening and should have happened to where I can really punch up someone else’s viewpoint and tell a much better story than they submitted just by virtue of, you know, having – being an objective observer and saying, “Well, what you submitted was okay, but this part – this part’s great.”

Alex: Do you guys happen to remember the ITAPPMONROBOT story about the –

Jane: Oh, yeah. Of course I do.

Remy: Oh, yeah.

Alex: It’s one of my absolute favorites, but if you go back to the original submission, and I don’t know if we’ve ever linked it. I know we shared it with the writers, obviously, as well, but, you know, the original submission, if memory serves correct, had to do with an anti-Windows – It was a “Windows is terrible, Linux is great” story. And to the submitter, that was the notable part is that Windows was so bad that he couldn’t reset the server remotely, so he programmed a Linux box to eject a CD drive. Mm, that’s kind of lame. Just – Who cares? Another “Oh, Windows is terrible” story. But we turned it into a much more memorable story. Same exact set of facts packaged and presented completely differently, and it went from being a rant that would be in the comments section somewhere to a pretty memorable story that is one of my favorites and, I think, a lot of readers’ favorites, as well.

Remy: On Jane’s point, there have been a few times where I’ve picked up a submission where the real WTF in this submission was the submitter.

Jane: Yeah.

Remy: You can read their story, and they’re trying to make this argument about how horrible everyone around them is, but you can see clearly they were the ones who were actually in the wrong. One of my personal rules is that, even if I read the submission and the submitter is the real WTF, I don’t write the story from that perspective. The submitter is always going to be the hero of the story, but maybe we move the actual problem or we express the problem in a slightly different way. There’s actually one that – It hasn’t run yet, but it’s going to run before this episode airs, and it falls kind of into that category. Ellis wrote a story called “The Automation Vigilante,” which – It’s actually about the person that, as developers, we tend to have a big problem with. They’re the non-developer who writes a bunch of macros to automate their job.

Alex: I love that title: “The Programmer Vigilante.” Just the image that that’s conjuring up and – Basically, it describes so many people that I’ve met in my career, as well. On the idea – This concept – So, programmer vigilante – It reminds me that one topic that was sort of on our shortlist to bring up today was something that – It wasn’t programmer vigilante. It was what? It was programmer anarchy. Programming anarchy.

Jane: So, I heard about programmer anarchy when I was looking up, you know, different types of agile and some out-there agile concepts. And basically what it is, as an elevator pitch, is a bunch of developers who fired all the managers, fired all the business analysts, fired all the Q.A. people, sat down with the stakeholders, and said, “We’re in charge now.”

Alex: Oh! That sounds about as successful as real-world anarchy.

Remy: This sounds like the textbook definition of the Dunning-Kruger effect.

Jane: Pretty much.

Alex: So, it’s an interesting concept, and I guess if no actual work needs to be done – Again, let’s say like real-world anarchy – I could see it working. But what is the context that this came from? Is this a methodology that’s espoused by, oh, I don’t know, somebody just who’s been completely embroiled in this Dunning-Kruger effect and thinks this is a good way to run a business?

Jane: Well, and that’s the fascinating part is that it worked really well for them. But the thing is, they started with a bunch of senior developers who really knew the business, inside and out, had been right there from the beginning, with the stakeholders. They worked in an industry that was very fast-paced, to where the biggest risk was not moving. So as long as you did something, even if it failed, you would come away with better payouts than doing nothing.

Alex: So, I guess it’s this idea that it turns out that, yes, they said they fired all the business people, they fired all the other folks, but they were those people. They had knowledge – very specific knowledge of whatever specific industry they were in, which completely invalidates the entire thing. That’s like saying, “Well, anarchy will work as long as it’s these 12 people on this island who will run it like a utopia.”

Jane: Yeah. I mean, that’s basically it. If you have a bunch of high-performing senior developers who know the business like the back of their hand, you could do anything and you would come away with a success.

Alex: Now, what I see we’re doing here, Jane, is that we are building up this wonderful effigy made of straw and then setting it ablaze. So, Remy, I’m hoping that you can come in and defend programmer anarchy.

Remy: I can, actually, Alex. And feel free to stop me, Jane, if I’m kind of going off the path, but I’m almost agreeing, actually, with Jane, even as I say I’m gonna defend programmer anarchy, because here’s a few things to keep in mind. First off, if you are engaged in any creative effort – and programming is a creative effort. I think we can agree on that much. It’s a technical field, but it’s very much a creative effort. If you are engaged in a creative effort, handing the reins to people who are passionate about what’s being created – now, not passionate for the tools, right? You don’t hire a sculptor because they love a chisel. You hire a sculptor because they are passionate about sculpting, right? So, people who are passionate about what they’re making, people who know the business, in this case, right, who are intimate with the business – Jane’s absolute right. You get those people involved, no matter what you do, you’re gonna see at least some degree of success. But here’s the other thing. In a lot of organizations, there is a big pile of management overhead, and I have actually said this many times. If you want to make an organization perform better, fire all the middle managers.

Alex: So, that’s a couple interesting points. Now, first, I don’t think I can let you get away with the
“programming is creative.” You know what’s creative? Music is creative. Sculpting is creative. Um, programming is engineering – solving a very specific problem to achieve a very specific business goal. Obviously, the mechanism of that problem is not well-defined, but that does not mean that it’s a creative endeavor.

Jane: See, I also have to disagree a little bit, Alex. I think you have to separate the act of programming from the more creative endeavor of software engineering. I think there’s a lot of different particular disciplines within, you know, computer science and within the art of making a program, some of which are more creative and some of which are purely mechanical.

Alex: Well, and that’s certainly fair, because software eventually does interact with users, but that’s a whole field of discipline called user experience, which is quite a bit different than, say, “Let’s figure out how to write a process map that takes this loan and runs it through a dozen different underwriting programs.”

Remy: If you are presented with a problem space – Let’s get programming out of here entirely. We’re building a factory. We need to take raw materials through a factory and get widgets on the other side. This is a broad problem space. There is a nearly infinite number of ways that we could accomplish that goal. There are definitely ways that are better than others. There are definitely ways that are almost equivalent but have certain tradeoffs that make them better in certain cases than others. And I would argue that the act of taking a huge problem space and cutting that problem space down to the appropriate solution is an act of creativity.

Alex: Ultimately, what we’re looking at is software that’s designed to implement a business process. A lot of times, software defines that business process, but when we’re saying that developing this code behind a pre-defined – And I’ll give you that there’s a creativity in defining that business process, but in implementing and in software, where’s the creativity outlet?

Jane: Being that, you know, I have my fingers in a lot pies – I’m sort of a modern Renaissance woman – one of the many things I am is a writer, and so, inevitably, my mind goes to try and liken software design to writing a novel – particularly a novel. A short story’s a little easier. But nobody can doubt that coming up with the idea for a novel and, you know, the setting and the plot is purely creative, but at the same time, typing the words on the keyboard is a purely mechanical task, to me, akin to writing lines of software code. There’s only one right way to spell each word, and there’s only a handful of right ways to link them together into sentences.

Remy: Jane, I really love that metaphor, because as you were saying it, it dawned on me – If you are in the process of writing a novel, one of the decisions that is both a mechanical decision and a creative decision is, in the space of an individual sentence, am I going to describe what I’m telling the reader about? I have a character who’s wearing a coat. Do I describe the coat in a literal description or do I provide a more metaphorical description or a simile that conjures a different image than the strict literal description? And that’s something that, if we were to think about this from a programming perspective, that’s a question about what abstraction tools we use to express an idea. So, here’s an example where there is that element of creative thought in programming where I could write a very literal program that uses almost no abstraction, right? I mean, go into your operating system, right? You go into kernel code, and kernel code is extremely literal. It expresses things in a very concrete fashion. For a more high-level language, we are gonna be using these more abstract tools, and that’s where a certain degree of expressiveness comes in, where there are a lot of ways to say the idea you want to say.

Jane: To do it well, at least.

Alex: Well, and I think, though, the same case could be made for every single engineering profession.

Remy: I agree.

Alex: Building a bridge, a skyscraper. But, you know, the difference between engineers, creative professionals, and programmers, who seem to want to live in both worlds when convenient for them, is that engineers have things like schedulers.

Remy: This is where I have to disagree with you on creative work so, so much. Because one of the creative endeavors that I have – and I’m strictly a hobbyist, and I am very bad – but I like directing short films. And if you are going out to direct a film, there are a lot of people and there are a lot of resources that you have to manage through that filmmaking process. That requires schedules. It requires budgets. It requires – You know, you have to have a call sheet that tells all of your cast and crew where to be when and what they’re gonna be doing once they get there. This is where you do need a management organization. And I know I’m kind of contradicting myself, ‘cause I just said, “Fire all the middle managers,” but I want to be specific there. Fire all the middle managers.

Alex: I mean, to an extent, but now you’re talking about – And this, I guess, was the point that I was driving towards, right, is that, you know, on the creative side, of course there’s deadlines, but you know what creative people do. They just work straight up until the deadline. If you want to work the eight-hour days, which, by the way, many, many people prefer to do, because this isn’t fun for them. This is work for them. So, for the people who do want to work those eight-hour days, we really do need to build structures, an organizational system of ways to manage the eight hours that each programmer, each developer, each analyst is able to work each day. And, you know, going to this middle manager notion – Of course they’re very, very valuable. Any good manager – what – eight to ten people? That’s about all that you can really manage as a team. What happens when you have 100 developers?

Remy: I think there’s a lot to mine on this topic. And I’d love to continue that, but I think that’s way too big a topic for this. Let’s pull it back to programmer anarchy as an organizational technique. And I want to hear Jane’s, you know, key thoughts and key takeaways about programmer anarchy.

Jane: Yeah, well, you know, to me, the most interesting thing that I found out about programmer anarchy when I was looking into it – The original white paper that they put together, they talked, you know, proudly about all the things they got rid of. They got rid of all the testing. They got rid of iterations. They got rid of user stories. They went to, like, a microservice architecture where, you know, they felt like they would never have to refactor code again because they can just delete it all and start over because each service was so small. They got rid of paired programming. And two years later, one of the two authors of the paper sat and, you know, went through, to him, how successful it was. And he says, “Well, if you look around the company today, everyone’s doing stand-ups. A lot of people ended up liking the idea of refactoring code because it was pleasant to them to see their code get progressively better over time. And they’ve started doing paired programming again because they miss the opportunity to learn from another developer.” So ultimately, what they discovered was that self-organizing teams are particularly effective when you have senior developers on them and, also, a lot of the things that were invented were invented for a reason.

Alex: That’s something that’s always fascinated me about organizations. We look at them, we mock them, but the reality is it’s kind of difficult to take billions of dollars and turn it into slightly more than billions of dollars. Programmer anarchy really speaks to this notion that a small group of self-organizing folks – I’d almost look at it as this notion of a strike team –you know, in military terms can just go in. A really good strike team, maybe of ten people, can clear an entire skyscraper, right, floor by floor. It’ll take a good one to do it, the most senior, most agile, ninja-level skills to do that, but there’s no way that even the best strike team in the world can take a block or a city, for that matter. That’s where you need an army. And I think that’s what we’re looking at here with programmer anarchy is it works just fine when you’ve got a strike team, but they’re not gonna be able to build a giant system. It’s just not possible because it’s too big for them.

Remy: I think that is an excellent point to wrap up this episode on. I think we’ve got some grist for the mill for some future episodes. Jane, I want to thank you for hanging out with us today on this podcast. I communicate with the writers mostly via e-mail, so it’s kind of a nice treat to actually get to hear one of the voices on the other side of that e-mail chain.

Jane: It was my pleasure.

Alex: Definitely, and hopefully you can join us for one of the Radio WTF things that I’m sure Lorne is working on and will have for us soonish.

Remy: Yeah, maybe the person who’s the editor of the site should contact Lorne and make sure that that’s going into progress. That’s, uh…

Alex: Remy, this is how you’ve ruined the site.

Anarchy for Sale.
[Advertisement] Atalasoft’s imaging SDKs come with APIs & pre-built controls for web viewing, browser scanning, annotating, & OCR/barcode capture. Try it for 30 days with included support.

Read all

CodeSOD: The Tokens That Wouldn’t Die

Expiration

Sacha received custody of a legacy Python API, and was tasked with implementing a fresh version of it.

He focused on authentication first. The existing API used JSON web tokens that, for some reason, never expired. Assignments like expiration=86400 and expiration=3600 were littered throughout the code, but seemed to go ignored.

It didn't take long to track down the token generating code and figure out the tokens' source of (near) immortality:


expInTS = calendar.timegm(datetime_tz.now().timetuple())
expiration_seconds = 86400
expiration = (datetime_tz.now() + datetime.timedelta(seconds=expiration_seconds))
return {'status': True,
        "auth_token": user.generate_auth_token(expiration=expInTS),
        'code': code,
        "token_expiration": expiration.strftime('%Y-%m-%dT%H:%M:%S'),
        'user': user.to_json()}, 200

Several expiration-related variables are set up at first, and even the original coder seemed to have gotten confused by them. When generating the token, he or she used expInTS for the expiration value instead of expiration. The problem is that expInTS is set to the current Unix timestamp—which is the number of seconds that have transpired since January 1, 1970.

The slip was confirmed when Sacha looked at a token header:

{
 alg: "HS256",
 exp: 2977106874,
 iat: 1488553437
}

iat (issued at) shows the Unix timestamp when the token was created. The timestamp was then added to itself, resulting in the timestamp for expiration shown in exp. That timestamp corresponds to May 4, 2064, a date by which most of us will be dead or retired.

Profound, yes, but not exactly desirable. Sacha adjusted the expiration value to 86400 seconds (1 day), then moved along.

[Advertisement] Release! is a light card game about software and the people who make it. Play with 2-5 people, or up to 10 with two copies - only $9.95 shipped!

Read all