Don’t Get Caught Up in a Code Framework Paradigm

I was originally going to name this article “How It Took Me 8 Hours to Write 2 Minutes of Code”, but somehow I didn’t think that most software engineers would find that terribly compelling, and if there is one thing engineers like to do, it’s to determine what’s most efficient and functional. Since you’re reading this, I guess this was the better idea.

It’s easy to underestimate what it means to be a software engineer. When most people think of a engineering position, they view a stereotypical computer nerd, with half a dozen bottles of Mountain Dew lying empty on their desk, Star Wars figures littered throughout their cube, and quotes from The Princess Bride printed out and taped onto their cube walls. Well, okay I can own that. Sort of.

What software engineers really are however are problem solvers. Every day we show up at our keyboards to bravely stare the unknown right in the face, and solve our client’s problems, even the ones that don’t exist quite yet, with creative and efficient solutions. I wish that “bravery” was a skill more people associated with the job.

What software engineers really are however are problem solvers.

If you are anything like me, it helps to have a sword and shield close at hand when daring greatly, and for me, that’s my favorite framework, which at the moment is Angular 5. Chances are, no matter what kind of programming you do, you likely have a popular, open-source framework of your own that you rely on daily. I know that, for me, as a UIUX front-end programmer, every problem that comes across my desk (my lap really, as I work from home) is likely to be solved by creating a new set of common, MVC-like files. First there’s a View, then a Controller, a Component, a Module, perhaps a Service, and several hundred lines of CLI generated code later, I’m ready to start solving any client’s needs.

Need to collect some profile data on your users? There’s a View for that!

Want to find the closest gas station to your zip code? It’s a mere Service away!

Desperate to find a love match? I’ve got a Module made just for you!

That’s how my day started yesterday. My client needed a new page added to the application site that will display some rudimentary reports. The report data itself could represent almost any kind of data stored in their massive database, and could also come with any number of unknown parameters required to generate the desired reports. Easy, right? There’s nothing like limitless parameters to make a guy feel all warm and fuzzy inside.

It took a full 6 bottles of Mountain Dew and most of the day (time was taken to play some Hearthstone, but I digress) and a shiny new Report page was born in true Angular style. The data was called up from a Web API, it determines if Parameters are needed, and if so, it dynamically generates all the forms and controls required to gather those Parameters, re-requests the Report data, and then renders the whole “shebang” on screen. Thank you very much and have a good night folks, I’m outta here. That’s why they pay me the sub-standard bucks.

Easy, right? There’s nothing like limitless parameters to make a guy feel all warm and fuzzy inside.

Today went a little differently however. This morning, the client requested a way to both print the report, and to save it to a PDF as well. Oh, and they are so happy with the new report module that they called their flagship client up and promised to demo the feature for them tomorrow (Isn’t it wonderful how sales people have no idea what QA is?), oh, and by the way, they also promised that it would be print and PDF ready, despite the fact that they hadn’t actually even mentioned that to me yet at the time. God I love my job. Someone please shoot me now.

No worries. This will be easy, right? I already have the report code, and it all is sitting in a

element on my page. So all I really need to do is create a new page that creates the exact same table, but without all the Master-Page stuff (the Header, Footer, Menu, etc.) sitting around it. Then I can add a Print Button and a Print To PDF button at the top, and boom, we’ll be done! This should take no time at all. Except it did.

I started the same way I start everything. I created a new page. But wait, everything new keeps using the same Master page, so I need to create a new Master without all the headers and footers and stuff, so I do that. But this is the only page we currently use that would need a “blank” Master, so now I have to create some new routing code and a new Store, and then I just re-create the report code from the report page on this new page, but wait… Ok, why be redundant? I’ll create a new Component from the Report code I already have and then I can just pop the Component into the old Report page and also the new Print Report page, and that will… oh crap. I have to gather all those parameters. Right. Okay. So if I do that in the new Component however, that means the end-user will have to select all those Parameters on the Report page, but when they go to the new Print Report page, they’ll have to select them all over again, and that’s not good. Crap. Okay. So can I just pass everything needed to the new page? But wow, that’s a lot of data to pass, and performance is going to take a hit here… Crap.

I started the same way I start everything.

I looked at the clock. I had already spent 8 hours screwing around with this code, following my “tried and true, framework way”, and what I had to show for it so far was a bunch a broken code, dozens of new files, a completely re-written way of displaying pages, tons of stuff that was going to affect anyone else working on the code, and I still didn’t have a way to print the damn report that seemed clean and functional to me. That was when the phone rang. It was my boss.

“How’s the print feature coming along? You got the PDF thing working too, right?” CRAP!!! I forgot all about the PDF thing. I hadn’t even stopped to research it. There’s a sweet and simple Angular 5 compatible PDF open source control, right? Right? I’m busy looking up jsPDF when my boss says she switched the meeting with the client to demo the new feature to tonight (Hasn’t anyone in this company ever heard of QA???) and that requiring the end-user to enter the Params twice just isn’t going to fly. Great.

What a mess. Here I am, 8 hours in, with a metric-shit-ton of useless and broken code, a Print Report page that still doesn’t work, and no PDF capability. Angular has failed me. MVC has failed me. Everything in my architecture has failed me, and most of all, I have failed myself and my client (who could really have not promised all this stuff so soon, but that’s another story). Now what?

And that, my friends, is the whole friggin point of this post. Today I fell into the stupidest trap a software engineer can fall into. As the old saying goes, “When the only tool you have is a hammer, everything looks like nail”. I was trying to code everything to fit into my framework paradigm, when all I had to do was solve the problem, and it was such a simple problem.

Today I fell into the stupidest trap a software engineer can fall into. As the old saying goes, “When the only tool you have is a hammer, everything looks like nail”.

No framework was needed. No new page was needed. No PDF control, no new Services, Modules, Components… nothing but about 5 lines of simple TypeScript code, and I could have had a whole day to get some actual work done instead.

private printReport() {
  const reportToPrint = document.getElementById('report');
  const newWin ='');

That’s it. All I had to do was gather up the HTML I already had, send it to a new window and tell it to print. And as a bonus, if they chose “Save to PDF” from the Print Dialog, it created a PDF file, no extra code required. What a moron I am.

The moral of my sad, cautionary tale is to stop, breathe, and think before going gently into that dark night. Our frameworks are wonderful, powerful and flexible hammers, but not all problems are nails, and clients can often make requests of us that don’t make sense. They can ask for a new page when a button will do, and as the engineers, it’s our job to step out of our own heads and see the problem for what it is, and not what existing model it can not-so-conveniently fit into. I lost sight of that today, and it cost me hours of wasted time and wasted code, and my client was more pleased with the “no name brand” solution I came up with then I can even tell you.

Now can someone please pass me some Advil? 6 bottles of Mountain Dew will give a fella a mean headache…

Please follow and like us: