Implementing Frontend Frameworks

Standard

If you’d asked me a year ago I would have been a Stalwart wall of denial when it came to the usefulness of frontend frameworks. I’d have argued anything you wanted to do on the frontend of your web application could be achieved with HTML, CSS and  Javascript.

To a point, a very small point, I was right. You can do everything you want using basic frontend technologies, but that doesn’t mean you should.

Realizing I was already using other frontend technologies was a good first step to seeing there could be more to them than I thought. Bootstrap, Foundation, Uikit or Pure would all give a great starting point when making a website responsive, so why make my own? The same thing went for JQuery. It is possible to do it all in JavaScript, but (again) why reinvent the wheel?

These frameworks are tried and tested, they have online communities for support and an array of resolved issues on Stackoverflow. That kind of support doesn’t exist when ex-employee Frank wrote the whole thing from scratch.

“So let’s see what’s out there.” I thought to myself

Short answer, a lot. At the time I looked there were loads of quite popular CSS/JS  libraries and frameworks. So what to pick?

I’d suggest looking inward at where you work to see what they use if you’re a backend developer exploring this frontend world for the first time. You’ll get a ton of opportunities to practice and see examples.

If you already know what your company uses, or you want to help them expand into something new, what then? A shortened list of frameworks is a great starting point. I started with what’s popular. Popularity means more online sources for assistance, more tutorials, more businesses adopting it, and it’s probably stood the test of time for a reason.

JavaScript CSS
Angular Bootstrap
React Foundation
Ember Pure

A note on the CSS side, I’d recommend looking into a precompiler. They aren’t a huge thing to learn and the benefits can be nice. (Not many to pick from, but I’d say you can’t go wrong with SASS or LESS)

Now I’m not going to state exactly what you should use, that’s for everyone to decide for themselves. As we all have different use cases. But I will cover what benefits they bring as a whole.

A good framework will assist you to produce modular, reusable code. Depending on what you’re using to start with, it can cut down on the frequency of server calls, and the amount of data you send and receive with each.  Not only is the code reusable, it’s also reliable and robust. It’s been iterated over many times by, let’s face it, better developers than you or I.

There are a few cons, though, not everything in sunshine and rainbows. Some of these frameworks can be implemented badly, installing Angular won’t magically make your project amazing, and sometimes a bad implementation can undo all the benefits. It’s may also be the case you didn’t really need a framework.

This leads to learning. If you’re looking at these technologies for a home project then infinite time,  infinite research and zero risks are all yours. If you’re looking at taking one of these technologies into your company’s’ next project, you’re in a different boat. You have a deadline and you may not have time outside of work to learn. This can make it impossible to sway some decision makers that it’s the right idea. Especially when they consider the whole team’s time. It can be hard to see the weeks lost to learning will pay back months later down the line, and sacrificing time on current projects can be a tough pill to swallow.

This usually ends up in some “learn while doing” middle ground. And as a developer, you have to say no to this. Speaking from experience, this just leads to an unmaintainable mess. Production turned into a testing site for the how best to implement the new technology. Take the time, learn it on side projects or prototypes, plan carefully how to best implement it. Your future self will thank you.

So in summary, do your research. Don’t feel obligated to use one if you’re unsure of its benefits to your project. If implementing at work, push for time to prototype and learn. If implementing at home, pick what you think is cool and have a blast.

For my upcoming home project, I’ve decided to leave my comfort zone completely. I will be tackling a new technology (to me) in every layer of the application. After much research along with some work factors. I’ll be using Angular2, node.js, SASS, mongoDB/dynamoDB, and bootstrap3 (maybe bootstrap 4). I’ll be covering each of these in a deep dive over the next coming weeks as I get a more hands on feel for them.

Responsibility

Standard

My next post was going to be a more technical post, but this topic has been relevant to me over the past few weeks. And as I have this blog, I thought it may make a good opportunity to share my thoughts.

Now a developers responsibilities may vary greatly depending on where you work, the size of the company and your seniority. I’ll take a general approach, but also target out some specifics.

First and foremost you are responsible for your work quality. What you send to QA is a representation of you and the effort you exerted. Did you unit test to minimize errors?  Did you test edge cases which debugging? Did you browser check cosmetics? These are things, I hope, a QA department will notice and cause your ticket to fail. So why waste time going backwards and forwards from QA when you could have spent that little extra time?

“But there wasn’t enough time”

That’s the general excuse I hear, and this brings me onto your next responsibility. Communication. When time constraints are tight and deadlines are looming, the first thing I see go out the window (from junior and senior developers alike) is testing. Unit testing, developer testing, sometimes testing it builds. Quality dips, corners are cut, and you start a game of ticket pong with QA.

To solve this, all you needed to do is communicate. This is particularly true for junior developers. Communicating the fact the item will take longer than expected can feel like you have failed. But honestly, no senior developer or manager I have ever worked with will think that. You’ve underestimated, missed something, or were blocked by something unforeseen. It happens to everyone, the best thing to do is communicate the issue and help resolve it. Delivering quality is always the goal, and once quality is brought into the equation everything else becomes secondary.

As you get into a more senior role, you will gain a responsibility of enforcing rules. Coding standards are important and you cannot let excuses of “Not enough time” or “I copied the from elsewhere” fly. Any code added has to abide by the current standards your company enforces. This involves making sure other senior developers are also enforcing the same rules. If one person fails something for not being unit tested properly and another person doesn’t, the code base will suffer and people will never learn how to improve.

Senior roles also have to lead (maybe not directly or officially) .This is a bit of an odd concept to some, but you’re in a role where you are above others in a hierarchy of ability. Naturally you are looked to for guidance and help by more junior developers. You have to support them, show them how to do things properly and assist them pushing back on legitimate issues like scope creep, unreasonable deadlines or code quality.

We are all also responsible for our own mistakes. Mitigating factors can come into play, but on the whole they are excuses. You cannot blame QA for missing something during testing that ended up on production. You wrote it, you also missed it, you’re also responsible. The ability to hold up your hand and admit your mistake separates developers at all levels. Admitting you’re fully or partly to blame will help resolve the issue quicker and, in my opinion, it shows a great level of maturity. Witch hunts will not help anything, it will waste time, and goes against your last responsibility.

Working as a team is a responsibility many ignore. You may not like your co-workers. You may think they’re incompetent. But you’re stuck with them, so make the most of it. You have the same goals, work on the same projects, and work on the same code base. If they are the person described above, who put a bug onto production, help them fix it. Do not leave them to deal with it as they caused it. Yes they are responsible for the quality of their code. Yes they are responsible for the bug, and yes they are responsible for fixing it. But you have the responsibility to the project. Which means helping them, and helping them learn.

I hope this helps some of you see where you can improve, or where you can help others improve. Knowing your responsibilities is important and will help you grow in the software industry.

 

 

Vaporware

Standard

Ever since the dawn of the commercial software industry there has been vaporware. The concept of selling what you don’t have, in a promise to make it later (sometimes even used as a false promise that will get quietly swept under the rug)

In the ideal business you’d be able to sell what you have, build or expand the features you want. Then sell and promote the new feature to keep customers and secure new ones. That is the ideal at least.

The reality is, however, that most companies (at some time or another) will fall into the trap of selling vaporware.

They’re always plenty of reasons:

  • “For the price the customer is paying, it’s worth the investment”
  • “The customer isn’t particularly happy with the software, so it’s an attempt to stop them moving to a competitor”
  • “We are planning to do that anyway, the customer is just extra incentive”
  • “Saying our product does this will get us into a new market”.
  • “Guarantee selling”

The issue starts with how much like a flood gate selling one bit of vaporware can be. Starting with small features, moving to full modules and sometimes even new products. The amount of work grows, but no matter how big the pile of future promised software gets, it only becomes unmanageable once deadlines are introduced.

Having multiple customers sold vaporware delivered by a particular date is a recipe for disaster (Particularly if insufficient effort has been put into the proper planning and time estimation). Prioritizing the work becomes near impossible, usually resulting in the work that was next on the to do list getting pushed back or unrealistic goals being set.

From my experience developers usually get little to no contingency and sometimes requests for overtime. And in the rush to get it done on time, quality takes a nose dive. The amount of time I’ve seen a development team cover for the promises of other departments will always astound me.

To a point, selling vaporware can be balanced well enough. Keeping the customer accurately informed is the key. One (maybe more depending on size) future promises can weave their way in the pipeline without much issue or pressure on the development team.

So what can you do? Honestly? Not much. Selling vaporware isn’t necessarily a problem if managed correctly. Meaning customers know it’s vaporware and realistic timescales, if any, are set in place. As a developer you will probably not notice if this is the case. However if its badly planned. What do you do then?

  • Speak out. Don’t let the promised deadline effect how long you think it will take to do the work correctly.
  • Don’t feel obligated to do overtime. It’s not your fault it’s been poorly planned. And if you’re okay with doing the overtime, negotiate a good overtime rate. It is your personal time you’re giving up.
  • Talk to your managers and other developers about it. It could be you have the wrong end of the stick, or your managers are unaware of the undue pressure across the department as nobody else has spoken up.

Hello world!

Standard

Hello world. As a starting point that seems pretty default for software engineers. But unlike lesson 1, I do plan to expand a bit in this initial post.

I plan to write a few articles a month about Coding practices, development methodologies, technology comparisons and what life is like as a software engineer today.