Published October 15, 2019 | Categories: Web Development
As a profession, software developers have a reputation for being, um... let's say eccentric. Or, quirky. Or, unique.
That's not a dig. Eccentricity is often a sign of brilliance. And, let's face it, you need to be darn-near brilliant in order to meticulously translate computer language into the beautiful, complex web experiences we all take for granted today.
"Coding is part art, part science," says Deb Paylor, one of Beacon's Project Managers who works closely with our in-house software development team. "Developers, it's almost like they have their fingerprint on their code, because they all do things a certain way."
Web development is a demanding profession that requires a combination of specialized knowledge, technical skills, abstract reasoning and the ability to problem-solve. That last part is especially important.
Why?
Because every developer routinely deals with code that's problematic – either because it wasn't written right the first time, is past its expiration date (too old to work properly with new applications) or has not been tested or implemented the right way. Bad code is, in a word, a nightmare.
This month, we had the privilege to sit down and talk to some of our esteemed in-house developers about their experiences. And, in honor of the holiday at the end of October (Halloween), we discussed a few of their "scariest" coding problems.
These nightmares are ghoulishly brought to you by Zedric "Zed" Myers (Senior Lead UI Developer), Emily Mallard (UI Developer), John Vine (Lead Software Engineer) and Wayne Garrett (UI Developer).
Legacy code is not always bad. It's just rarely good.
What is legacy code? It isn't necessarily code that didn't age well. According to Technopedia, legacy code is "an application system source code that is no longer supported."
When that happens, it is oftentimes quicker and easier to patch existing legacy code, rather than switch everything to a new version. And, that typically leads to issues.
Here's Emily describing a typical experience with legacy code:
"Legacy code can be real finicky. If you don't do things to the 'T' in it, it'll break. It'll just completely break.
Before updated code comes out, a developer might need to add to the legacy code, but will do so in real hacky way. Later on, if you have to apply a fix or a patch, it'll just explode everything. I'll change just one line to something that I hope will work, and it'll break the entire thing. The whole page then becomes non-functional."
It's not uncommon for several developers to work on the same piece of code. We're also sometimes asked to work with a third-party developer on a particular project. If everyone is not on the same page, following the same procedures, major headaches – re-work, fixes, delays, etc – are likely to occur. Ask any project manager about the impact of delays on a web design project – it scares the bejeezus out of them.
Having good standard processes is important in any profession. It is even more so in software engineering, where you're dealing with highly technical elements that can be approached in a number of different ways. Bad processes, or instances of established processes not being followed, are as nightmarish as Freddy Krueger walking down Elm Street.
"Good, clear processes can save hours of development time and stress," says Zed. "If another developer needs to jump in to help, they know exactly what to do without questioning."
That's why coders appreciate standardized processes and a good "paper" trail with clear documentation of what needs to be accomplished, what has been accomplished and what has yet to be completed.
Speaking of documentation... it can be difficult to finish a project if you're missing specific descriptions of what you're trying to build. Good documentation also makes complex projects easy to understand and replicate. For example, if someone wanted to follow up on Dr. Frankenstein's work, they could attempt to re-create the monster from the doctor's lab notes.
More from Zed:
"If you don’t have a clear focus on what needs to be accomplished, it can lead to hours of extra work, or even worse, scrapping the project and starting over. It's essential to have clear and agreed upon documentation with the client, so that they know exactly what they are getting."
Software engineers rely on something called functional requirements to guide their work. Functional requirements, sometimes also called functional specifications, describe the intended behavior of the software being created. A very simple example of a functional requirement is text appearing when the mouse is pointed at a hyperlink (hover effect).
Functional requirements are the roadmap for the software development team to follow. Working without such a roadmap makes the job a whole lot harder.
At Beacon, we utilize three separate environments when working on a website. This setup isolates work that's still under development from pages that are ready to be reviewed and published.
The first environment is the developers playground – which is why it's called Development. This is the workshop or factory where developers write new code and create various elements, pages or modules. It's the "behind the scenes" section with restricted access.
The second environment – which we refer to as the Test environment – is used to review how all elements on a given page interact and work with one another. This is where issues are found and resolved via our systems testing protocols. Once system testing is complete, we turn the environment over to the client for user acceptance testing (UAT). That's where the client has the chance to review the near-final version of the site and make sure that everything works as it was intended.
Last, we have the Production environment. This is where the live website lives. Once clients have reviewed and approved the work, it gets pushed from Test to Production.
Having three distinct places, each with a defined purpose, works well for developers, project managers and clients. Modeling the final product in a testing environment can be confusing for people not well-versed in software development projects. There's a clear benefit to having a separate environment for clients to review the work before it is seen by the entire world.
As you can imagine, having just one environment can create a lot of confusion for all involved parties. Not to mention that any changes you apply in production are out there for the whole world to see. And while that may be fine for small changes, it's a much bigger, more noticeable, deal if you're revamping the design of the entire site or heavily altering the content structure of a page.
Is your site ready for a refresh? An outdated site design can feel like walking through a dark cemetery without a flashlight. Don't be scared – Beacon is here to help. We know how to bring a website back from the dead. Mwahahahaha....
