Using Docker to Increase Developer Efficiency

Docker is a cross-platform program for building and deploying containerized software. It enables faster, more efficient development while reducing maintenance complexity in the long run.

As technology – especially enterprise technology- races forward at breakneck speed, it’s both a good and a bad time to be in the software business.

On one hand, there’s plenty of work for skilled developers. On the other, there may be too much work.

The enterprise software market is expected to grow 8.3% this year, and experts suggest it would grow faster if there were enough developers to meet the demand.

Faced with this pressure to produce more and better software, developers’ toolkits are expanding.

The priority now is technology that improves development speed and efficiency- tools like Docker.

What is Docker?

Docker is a cross-platform virtualization program used to create containers: lightweight, portable, self-contained environments where software runs independently of other software installed on the host machine.

Containers are largely isolated from each other and communicate through specific channels.

They contain their own application, tools, libraries and configuration files, but they’re still more lightweight than virtual machines.

Though container technology has been around since 2008, Docker’s release in late 2013 boosted their popularity. The program featured simple tooling that created an easy path for adoption.

Now, it’s a favorite DevOps tool which facilitates the work of developers and system administrators alike.

The Power of Containers

Containerization provides a workaround for some irritating development hurdles. For instance, running several different applications in a single environment causes complexity.

The individual components don’t always work well together, and managing updates gets complicated fast.

Containers solve these problems by separating applications into independent modules.

They feed into the enterprise-oriented microservice architecture style, letting developers work on different parts of an application simultaneously.

This increases the speed and efficiency of development while making applications that are easier to maintain and update.

Taken as a whole, it’s obvious why both software developers and IT teams like containers.

The technology enables the rapid, iterative development and testing cycles which lie at the core of Agile methodologies.

It also takes the burden of dependency management off system administrators, who can then focus on runtime tasks (such as logging, monitoring, lifecycle management and resource utilization).

Why Docker Is the Right Choice

Docker isn’t the only containerization software around, but it is the industry standard.

It’s a robust, easy-to-use API and ecosystem that makes using containers more approachable to developers and more enterprise-ready.

The program has an edge on previous solutions when it comes to portability and flexibility.

Using Docker simplifies the process of coordinating and chaining together container actions, and it can be done faster than on virtual machines.

Docker removes dependencies and allows code to interact with the container instead of the server (Docker handles server interactions).

Plus, there’s a large repository of images available:

Getting up to speed with Docker doesn’t take long. The documentation is thorough, and there are plenty of tutorials online for self-taught developers.

Docker In Action: The Financial Times

The Financial Times is a London newspaper founded in 1888. Their online portal,, provides current business and economic news to an international audience.

The media outlet was one of the earlier adopters of Docker back in 2015. Docker containers helped cut their server costs by 80%.

Additionally, they were able to increase their productivity from 12 releases per year to 2,200.

Looking Forward

Last year, the median container density per host rose 50% from the previous year.

In fact, the application container market is poised to explode over the next five years.  Experts predict that annual revenue will quadruple, rising from $749 million in 2016 to over $3.4 billion by 2021.

Docker specifically still leads the pack despite the niche popularity of emerging tools.

83% of developers use Docker. CoreOS trails well behind it at 12% with Mesos Containerizer at 4%.

Overall, Docker Containers is a highly enterprise-oriented solution.

Other tools are emerging to add functionality (like container orchestration platform Kubernetes), so there’s no reason it shouldn’t continue growing in popularity.

Concepta focuses on enterprise-ready tools like Docker that let us target our clients’ specific needs. To explore solutions for your own business goals, set up a complimentary appointment today!

Request a Consultation

Why Less (Code) Is More


Writing less code helps developers build clean, functional software that’s easy to maintain over time.

Ask any industry expert what makes a good developer and they’ll offer a variety of answers.

Broad technical experience, good communication skills, and excellent time management head the list. Those are all useful characteristics.

However, there is one trait that usually gets overlooked, something that has an enormous impact on both the development process and final quality: the ability to write lean, concise code.

The best developers know how to get more mileage from less code.

It’s an especially important skill in this era of reusable code, when the availability of ready-made components provides so many shortcuts for busy developers.

Those components represent a huge step forward by cutting the amount of tedious programming required in the early stages of a project.

The downside is that these development tools make it easy for inexperienced developers to write bulky code.

By flipping the script – focusing on writing less code instead of faster code – developers can build reliable software with low technical debt.

What Do Developers Do (Really)?

Developers are subject matter experts with the technical skills to build and maintain software.

hey work to understand technology in order to create technology-based solutions for real world problems.

Nowhere in that description does it say, “write code”.

Code is obviously how the technology gets built, but it should be seen as a means to an end rather than the whole job description.

Developers need to combine business sense, problem-solving skills, and technical knowledge if they want to deliver the best value to their clients.

Too often, developers forget their true purpose.

They write code according to habit, personal style, or excitement over a new tool they’ve been hoping to use instead of prioritizing ease of maintenance and scalability.

The result is software with a huge code base and a shortened usable life.

The Code Economy Advantage

When it comes to code, more is actually less. The odds of project failure go up as the code size increases.

After all, more code translates into more chances for something to go wrong.

One area of concern is bugs that make it into the final software.  The industry average ranges from 15-50 errors per 1000 lines of code delivered.

Projects with sizable code bases are going to have more flaws as a flat statistical reality.

Denser code is less likely to be read thoroughly, too, which means the ratio of errors to code will fall towards the higher end of that scale.

Having more lines of code also leads to higher technical debt.

Future maintainers (and anyone trying to update the software) must navigate that code to fix bugs, add features, and integrate the software with future systems.

Software development is a place where labor is a significant expense. When time spent on development and maintenance rises with a program’s size, it spurs an equal rise in IT spending.

There’s another increase in developer overhead from additional meetings and longer on-boarding processes when new team members are added.

Considering all of this, there are clear advantages to emphasizing concise code, both in cost and quality.

Code written efficiently and directly is:

  • Simple to maintain
  • Easy to understand
  • More flexible
  • Ages better
  • Easier to update and build onto
  • Reusable & elegant

Developers should work to write as much code as they need to get the job done correctly- and no more.

Why Developers Get “Code Happy”

If writing less code has such a powerful effect, why do developers continue to write far more code than is actually needed?

There are a few typical motivations:

Desire for Productivity

In some agencies, lines of code is used as a measure of productivity. The thinking goes that more lines of code – often abbreviated to LoC – equals more work done.

This is particularly common when running distributed teams who typically work without in-person direction.

The problem is that measuring productivity by LoC completed leads to sloppy writing and a focus on quantity over quality.

It’s like measuring a hotel’s success by how many towels they use; the fact has some bearing on success but can be very misleading.

Misaligned Priorities

Software development always involves trade-offs: simplicity versus feature richness, security versus performance, speed over space.

Sometimes the value of writing less code gets lost in the shuffle.

There’s no unimportant component of development.

Every project has different demands that require a tailored approach.

However, brevity is important enough that it should always be a high priority.

Personal Preference

Developers tend to be “code geeks”. They like to write a bunch of software and try new things purely for the sake of trying new things.

It’s a great quality when they’re learning or experimenting.

However, it’s not the best idea when working on enterprise software. The approach usually results in four times as many lines of code as needed for a task.

Developers need to direct their talent towards building software that meets the product owner’s goals even when that conflicts with their personal preferences.

Lack of Skill

Writing clean, concise code takes skill and practice.

Often less-experienced developers don’t know how to reduce LoC without cutting features or impacting performance.

Almost everyone does this in the beginning, but getting past it is part of honing developer skills.


Developers all learned their trade somewhere.

Every school of thought and development philosophy imposes certain ideas about how to make code more readable.

The issue arises when holding to convention comes at the expense of code economy.

As much as 54% of LoC are inspired by convention as opposed to utility.

Creating whitespace, intentionally skipping lines, and linguistic keywords are examples.

There are ways to improve readability without conventions that pad out the code base.

How to Write Less Code?

Making something complex look simple is hard, but it’s very easy to complicate simple things. Code economy is like that.

These are a few straightforward guidelines that can help developers get past complexity and write less code.

Build on an Existing Foundation

There’s no reason to reinvent the wheel. Use libraries instead of recreating what others have done well countless times.

Innovation should be saved for problems that don’t already have good solutions.

The Right Black Boxes are Good

Choose tools that enable code efficiency.

The Chrome V8 JavaScript Engine powers NodeJS, React Native, Electron, and Chrome Browser with 1,884,670 lines of code.

Be Careful Selecting Dependencies & Frameworks

Anything used should be mature, well-supported, and preferably have already proven its worth in practice.

Prioritize lean and simple frameworks whenever possible.

It’s also important to consider the size of the community and strength of company backing so future developers will have an easier time working with the code.

Reframe “LoC written” as “LoC spent”

Break down the connection between LoC and assumed productivity by changing the way it’s measured.

Instead of counting how many lines a developer was able to write, measure how many they needed to get the job done.

Compare it to a golf score: the fewer LoC that can be written while still delivering a good product and meeting sprint deadlines, the better.

Spend some time during the planning phase to brainstorm how less code can be written.

Planning ahead instead of charging in allows more opportunities for code economy.

The Code Economy Mindset

A huge part of writing less code is maintaining a direct, economical mindset.

Optimize code for correctness, simplicity, and brevity.

Don’t depend on assumptions that aren’t contained in the code, and never use three lines where one is just as readable and effective.

Make consistent style choices that are easy to understand. Avoid “run on coding sentences” by breaking different thoughts and concepts into separate LoC.

Only add code that will be used now, too.

There’s a tendency to try and prepare for the future by guessing what might be needed and adding in the foundations of those tools.

It seems like a smart approach, but in practice it causes problems, mainly:

  • Guesses about what may be useful in the future may be wrong.
  • Time spent writing code that won’t be used yet can delay the product’s launch.
  • Extra work translates into a higher investment before the product has even proven its worth or begun generating ROI.

Abstracting is another practice that should only be done according to present need. Do not abstract for the future.

Along these same lines, don’t add in comments or TODOs.

This messy habit encourages sloppy code that can’t be understood on its own.

Comments are more easily accessed when placed where everyone can read them using inline documentation.

Reusable code is a major asset, but make sure it’s fully understood instead of blindly copying and pasting to save time.

Try to choose options that follow good code economy guidelines.

Finally, don’t rush through development with the idea of refactoring later on.

The assumption that refactoring is “inevitable” leads to software that already needs work at launch.

It is possible to create a solid product with low technical debt by writing clean, concise code up front.

Keep A Hand on The Reins

Most importantly, don’t go too far by trying to use the absolute minimum LoC over more practical concerns.

As discussed earlier, a developer’s job is to solve problems.

When minimalist code is forced to override other needs, it becomes part of the problem instead of a solution.

Writing less code helps our developers create technology-based enterprise solutions with a long shelf life. Set up a free consultation to find out how we can solve your company’s most urgent business problems!

Request a Consultation

What’s the Point of PropTypes In React?


PropTypes is one of React’s most useful accessories. It provides clear, enduring assertions as to the type of data a React component needs to render properly.

The tool is built-in and ready to use without wading through complicated set-up procedures.

However, some developers bypass PropTypes because of the small amount of extra up-front coding required. That has the potential to be a serious mistake. PropTypes (and the variety of similar static type checking tools) is a valuable asset for building scalable, maintainable software.

Laying the Groundwork

To explain how PropTypes works and what it brings to the table, it’s important to understand some relevant terms.

An “assertion” is a forceful, definitive statement, whether it’s about a fact or an opinion. In programming, that statement is that something specific is always true at a certain point in code execution.

Data types, which are usually referred to as types, group similar values on which common operations can be performed.

Types are a classification identifying possible values, the amount of memory allocated to save a value, and the kinds of operations and methods which can logically be used performed on them.

JavaScript has six regular types:  string, number, undefined, null, boolean, and symbol. Some have more variety than others. “String” refers to any string, for example, and “number” has a similarly wide scope.

Other types are more restricted. “Boolean” is a binary type, undefined is a default type for any undefined variables, and null indicates there is no variable declared at all.

While this sounds complex, it’s highly intuitive in practice. Given a string of numbers it’s easy to see they can be summed but not merged without changing the meaning. 2, 5, and 76 is much different than 2576.

Conversely, though a series of words can’t be summed it could be merged. “I”, “love”, and “Orlando” is easily read even when merged to “I love Orlando”.

What is Type Checking?

Types are one of the main foundations of a programming language. Errors in defining them can derail a program entirely. In fact, many execution errors in JavaScript are type errors- for instance, trying to divide by a string.

Type checking involves making runtime assertions about the correct type of data a component requires in order to render properly. It’s independent of build time type checking.

Using the previous example, type checking would catch that it’s impossible to divide “42” by “Dent” because division isn’t an operation which can be performed with a string.

Merging “Arthur” and “Dent” into “Arthur Dent” won’t cause a problem since the “merge” operation is logically allowed for strings.

The most common tools for type checking are Microsoft’s TypeScript and Facebook’s Flow. However, when working in React there’s already a low-maintenance, easy to learn tool for type checking built into the code base: PropTypes.

PropTypes validates the data types of values as they’re passed through types. It can also flag types as mandatory or set default values to reduce the workload.

The Case for Type Checking

Developers coming to JavaScript from other languages may be used to catching errors elsewhere in the process.

This is especially true with Python, where type isn’t necessarily the best description of the restrictions the developer is trying to impose on their input.

With JavaScript, though, there are three major benefits to making the time for type checking.

Technical and structural fitness

Props are necessary to pass any value to a child component. They serve as the component’s interface to get data passed down the component tree.

Without type checking (using PropTypes or some other tool) developers risk passing the wrong data types to components. This has a negative impact on the application’s performance and can lead to crashes.

On top of that, PropTypes help catch bugs by validating data types as they pass through. This is useful as an application scales and the codebase grows

Efficient teamwork

In Agile development, using PropTypes enables better coordination between teams working on different part of the same project. They serve as documentation of how a component has to be used in terms of passing props.

This helps people who use the component later know what they can and can’t do and how to use it effectively.


Finally, using PropTypes is simply good business sense. They reduce the amount of time spent on debugging and testing.

Less time and higher developer productivity translate into lower ongoing maintenance costs for complex applications.

How PropTypes Works

Now that the value of using PropTypes has been established, it’s time to take a look at how it actually works.

PropTypes is React’s built-in type-checking tool. PropTypes is both the name for the tool and a reference to actual PropTypes, so it’s common to see it used both singularly and in plural.

In simple terms, the tool defines the type of a prop (string, number, undefined, null, boolean, or symbol). It then exports a range of validators that can be used to make sure the data received is correct.

Every time a value is passed through a prop it’s validated for type. (“Is this a number?”) When an invalid value is provided for a prop, a warning shows up in the JavaScript console to alert developers of the issue.

There are more options for specifying types and how they’re assigned, too. Developers can specify that only a single type can be passed to a component’s children.

They can also define default values for props using “defaultProps”. React set things up so that PropTypes type checking happens after default props are resolved, so type checking will also apply to those default props as well.

It’s important to note that PropTypes doesn’t throw errors. It only shows warnings in the JavaScript console, and PropType Checking is disabled in development. It’s a guide for better development, not a safety net for messy code.

Benefits of PropTypes

The biggest advantage of PropTypes is shared with other type checkers. It makes it easy to catch bugs caused by passing data in the wrong data type (like a string in a Boolean space).

PropTypes has an edge in that it is already built into React. It’s ready to use with a very gentle learning curve. Anyone that uses the component down the road can find all available props, including their desired data type, in one place.

Some code editors support code completion for props, so it’s possible to see the available props while typing in the component in a tooltip.

What Else Is Out There?

As mentioned earlier, the two most common alternatives to PropTypes are TypeScript and Flow.


A strongly typed superset of JavaScript created and maintained by Microsoft. It’s dominant in the Angular community but also used outside it, for example in React.

TypeScript has a larger community and it a more established and proven product. Users find it faster than Flow. As an additional edge, TypeScript is both a type checker and a transpiler that produces pure JavaScript.

Flow requires Babel or something similar to remove type annotations.


A static type checker from Facebook, which also maintains React. Because both fall under the same owner Flow is well-tailored to play well with React, with easy integration & automated refactoring.

Though it’s intuitive and efficient for use in building React and ReactNative applications, Flow has some drawbacks. Many in the community have commented on its weak documentation.

Also, it’s impossible to ignore type errors that come from components outside the developer’s control (like Node modules). New mistakes might get lost in the flood of old type errors passed down from those external components, and there’s no way to hide those alerts or shift them to another list.

Flow is a newer tool, which comes with its own suit of benefits and limitations. Facebook is constantly working out problems and experimenting with new functionalities.

The resulting frequent, sometimes extreme version changes can be hard for developers to manage.

In practice, the best solution is a combination of tools. There’s no downside to integrating PropTypes into the development process, even if Flow or TypeScript is also being used.

It doesn’t take much time to configure and saves a lot more in terms of maintenance, quality control, and developer frustration.

Final Thoughts

Static type analysis (another term for type checking) is a highly practical way to reduce technical debt. It lends itself to the creation of a codebase which is easier to work with, has fewer bugs, and supports Agile development methods.

Using type-checking to avoid errors does extend the working lifespan of a component, too. Developers tend to prefer better documentation and clarity of requirements, and they’re more likely to reuse components that are simple to understand.

From a business standpoint, PropTypes should be an easy sell. It’s simple to set up, intuitive to use, and adds an extra layer of automated quality control.

In short, unless there’s a compelling reason not to, take the time to set up PropTypes whenever using React or React Native. The potential benefits far outweigh the minimal set-up time.

At Concepta, our clients’ business goals are also ours. Building quality software with a long working life – in part by using tools like PropTypes – is just one way we work to protect your technology investment. Set up a free, no obligation meeting to talk about where your company is going and how Concepta can get you there faster!

Request a Consultation

How to Train Employees on New Technology

Originally published Jul. 20, 2016, updated Oct. 11, 2018.

The best software on Earth is a failure if the team can’t use it.

Support employees throughout the training process by offering technical assistance, providing a variety of reference formats, and fostering a culture of communication and collaboration.

After all the effort of finding the right enterprise software package, negotiating a sale, and supervising installation, the new program is finally up and running. It’s time to relax.

Well… it’s almost time to relax.

Before companies can start enjoying the benefits of their new software, they need to get over the biggest hurdle of integrating technology: training employees. This is a make or-break-moment.

The best program on Earth is a failure if the team can’t use it. In fact, over half of enterprise software initiatives don’t reach their full potential due to low adoption rates.

The problem is that employees tend to push back against learning new software. They’re already comfortable working around the flaws in the existing system, and they get frustrated with the disruption that comes with even good changes.

This sometimes leaves the impression that the old way was better.

Making the training process as painless as possible encourages employees to get behind new software. Read on for a few ways executives can smooth the path for them.

Provide Quality Technical Assistance

Offering technical assistance is the most influential step companies can take to help their teams learn new software.

This should include both initial software training and supplemental references for troubleshooting issues that come up in the early stages of implementation. The impact of technical assistance is undeniable.

The Primary Care Information Project (PCIP) and Weill Cornell Medical College conducted a study of how health practitioners implemented Electronic Health Records (EHR) and found that small practices without sufficient training resources struggled the most with their EHR systems.

Medical practices that received eight or more training and support visits had the highest levels of success.

When interviewing vendors, ask about their after-sale support. Plan to have a variety of resources and technical references that everyone can use for ongoing training.

Focus On What Matters

As much as 60% of software features are never used. This happens so often there’s a name for it: “shelf-ware”.

To some extent, shelf-ware is inevitable. Commercial software developers need to appeal to as many users as possible. They’re constantly adding new features in a quest to widen their customer base and stay relevant.

The resulting software has a host of shelf-ware most users will never touch.

Don’t make the mistake of trying to teach every esoteric function in the program during training. Focus on the 20-40% of commonly-used features and just touch on the rest.

Leverage Influential Users

In every group there are users who adapt quickly to new software. They’re comfortable with technology and like helping others who run into trouble.

Leverage their enthusiasm by designating them as transitional training leaders.

They can solve low-level problems for their co-workers and maintain any reference tools. It helps to give them a small bonus or other incentive, as well.

Address Problems Early

Communication is key when the training is finished and the software goes live.

Even the most experienced companies experience bottlenecks and setbacks when integrating new technology into their workflows. The only way to overcome these challenges is through communication.

Schedule meetings once every week or two where the whole team can share what’s working and where there could be improvement.

Check in with individual employees between progress meetings. Keep the conversation casual and talk to a variety of team members.

Managers, supervisors, support staff, and even outside vendors have unique perspectives that can help identify problem areas.

Once those issues are identified, schedule additional training on a group or using the transitional training leaders. Early intervention keeps frustration levels down, so employees aren’t tempted to go slide back into the old system.

Use Online Training Materials

Many vendors have extensive training materials on their sites, including videos, walk-throughs, information guides, and downloadable reports.

Self-paced training like this offers another avenue for employees to build their skills and gain confidence in the new software program. Share vendor resources where everyone who works with the software can find them at need.

It’s not always easy to convince employees to use new technology, but the payoff is worth it.

Support the team with quality training options, step in when there’s an issue, and foster an environment of collaborative training. When the employees have the right tools to learn, the project is on the best path to success.

How can your sales, marketing, and finance teams get rid of spreadsheets and become more efficient with their reporting? Download our eBook How to Implement Business Intelligence in Your Company to find out!

Request a Consultation

10 Database Design Best Practices


Originally published Nov. 18, 2016, updated Sept. 6, 2018.

Good database design is essential to building scalable, high-performance applications. 

A database is nothing more than a mass of information stored in a framework that makes it easier to search.

Everything else is just details. If a database works well, bits of related information are filed automatically and details can be pulled out needed.

It should be simple to draw new meaning from data by compiling it into reports and visualizations, then storing away those facts for later use.

Within that simple definition, there is infinite variation. Small decisions in the beginning have a huge cumulative impact.

Follow these guidelines to avoid common missteps that can affect software down the road.

Database Design Best Practices

Before defining a single field on a project, look over these 10 database design best practices that can dramatically simplify the development process.

1. Consider Every Viewpoint During Planning

Don’t start building a database without input from the project sponsor and other stakeholders.

Get consensus on precise expectations, and consider how hard it will be to train users on the search functions.

2. Choose A Database Type

This is usually as easy as deciding between SQL and NoSQL (though there are more specific types that may be appropriate for some projects).

SQL databases are the standard for structured data, when data integrity is absolutely important.

Emerging technology like machine learning or the Internet of Things (IoT) find the speed, scalability, and fluid requirements of NoSQL databases a better fit.

Web analytics, social networks and some other types of databases also work much better within the NoSQL framework.

Make the decision as early as possible.

3. Normalize Your Data

In reality, most companies today function in a hybrid world of SQL and NoSQL databases that work together in complex arrangements.

With such a complicated structure, it’s critical to normalize data to achieve minimum redundancy.

Eliminate multi-valued attributes and repeated attributes, then start in on the subkeys.

4. Make Structures Transparent

The database belongs to its future users, not its creator, so design with them in mind.

Stay away from shortcuts, abbreviations, or plurals. Use consistent naming conventions.

Don’t reinvent the wheel or make things difficult for those who may need to modify the database at some point, which will certainly happen.

5. Define Constraints to Maintain Data Integrity

Look into the full range of options to enforce business rules, such as foreign key, check, not null, and the like.

The application will prevent some bad data from getting in, but not all of it.

6. Document Everything

No matter how annoying it may seem, documentation is as essential as primary keys.

Take care to document the design, entity-relationship schemas, and triggers for future users.

7. Plan for Increasing Backup Time in the Build

Before delving too deeply into design, think about what happens during a natural or man-made disaster.

Plan for failover clustering, auto backups, replication and any other procedures necessary to ensure that the database structure remains intact.

As the saying goes, “Prepare and prevent, don’t repair and repent.”

8. Keep Privacy Primary

The GDPR signals an era of increasing privacy concerns.

Encrypt passwords, and don’t assign an administrator without privacy training and well-documented qualifications.

This can be a tricky rule to follow due to office politics, but as a good security practice the database should be as closed as possible.

Vulnerabilities impact data integrity, which impacts everything else in the enterprise.

9. Optimize for Speed

Create indexes for queries that will be used regularly. Use a database analyzer to determine if an index or a clustered index is necessary.

Consider incorporating tools like Elastisearch to speed up searches.

10. Keep the Database on Its Own Server

Put the database on a different server than the web to lower CPU usage.

In addition to freeing up compute resources, it also helps to keep the database out of the reach of unauthorized users.

Final Thoughts

Remember, database frameworks are not set in stone.

The current database workflows can be refined and directed, or even broken up, when it make sense.

Just as business directives change over time, the database will also need fine tuning to stay in line with the company’s current goals.

Too often, administrators get bogged down in thinking about how the database functions at the moment without considering what it is capable of doing in the future.

Instead of thinking, “It doesn’t work like that,” start from the viewpoint of “What is the end goal, and how can we get there?”

Having trouble deciding between database styles? Sit down with one of Concepta’s developers to discuss your unique requirements and how to build the best foundation for your next software project!

Request a Consultation

Learning From Equifax’s Example: the Risks of Outdated Software

Source: Pexels

Digital security is one of the most pressing concerns for executives in 2018. Companies have access to more customer data than ever before. While that opens the door for customized service and efficient processes, it also carries the responsibility to safeguard that data.

That goes beyond using encryption tools. Some of the most high-profile data breaches have been caused by an easily avoidable problem: out of date software.

A Costly Oversight

Failing to update seems like a slight oversight, but it can be a costly mistake. Performance suffers when software isn’t running the most current version, causing reduced efficiency poor user experience. It’s also important to consider the opportunity cost of not having new features available.

More importantly, though, is the very real security risk posed by outdated software. Vendors maintain their products for a reason: it may contain bugs or vulnerabilities which threaten the security of a company’s data. Most of the time vendors manage to close off those weak points before malicious actors find them, but that does no good if companies don’t download their fixes.

Last year’s catastrophic Equifax breach was a result of a known software vulnerability which the vendor had already addressed through an update – an update that was available for two months before the breach. 143 million people’s names, social security numbers, and addresses were exposed, and the company is still paying for cleanup.

The worst part is that the breach was completely avoidable. Updating would have taken a very short time, but it wasn’t seen as a priority until it was too late.

Staying On Top Of Updates

While the consequences of being out of date can be dire, it’s easily avoidable. Just follow these four basic steps to make sure everything is as current as possible.

Set up automatic updates

During initial software setup, choose the automatic update option when it’s offered. Automated maintenance is one of the biggest advantages of third-party software; don’t give that support away.

Even when automatic updates are selected, make a point to check for new updates regularly. Some programs only update at preset intervals. Those may be too long to avoid a risk if the company releases a time-sensitive patch.

Be mindful of web browsers and plug-ins

Outdated web browsers and plug-ins are a common security risk. Plug-ins are a rising trend in Shadow IT. Many employees don’t even regard them as “real software”, and they tend to click past update suggestions when they’re busy.

To see if there’s a potential insecurity, go to “Tools” in the browser’s “Help” menu and look for updates. It’s usually possible to set the browser to find and install updates automatically, but some niche plug-ins will need to be updated manually.

Restart computers daily

The majority of users like to keep their computers on and simply put them to sleep at the end of the workday. Work can then start right away in the morning, with all the tabs and documents from the day before open.

This seems like an efficient work process, but that efficiency comes at the cost of security. Updates need to be installed, requiring a restart for changes to take effect. Emphasize the need to download updates and restart all computers at least once a day.

The increased performance and avoided risk is well worth a few extra minutes to get organized in the morning.

Conduct regular audits

The longer a vulnerability remains in place, the more opportunity there is for disaster. Set up company-wide audits periodically to find out of date software and fix it before disaster strikes.

This doesn’t need to be a lengthy ordeal. Maintain a running list of all software used within the company by department including plug-ins, apps, and anything else that touches the company’s digital assets.

Every month, have managers go down the list and confirm that each is fully up to date, then pass the update on to IT. (As a bonus, keeping this list current informs digital transformation efforts by keeping leaders in the loop about software usage.)

Final Thoughts

Despite the occasional annoyance of an update popping up in the middle of the workday, installing them is free, fast, and easy. It’s also the simplest, most effective step in a corporate digital security plan. Don’t let a momentary inconvenience put the company at risk for a lasting crisis.

Part of good software development is making everything our developers use is up to date to protect our clients’ software. To find out more about our security policies and discuss how we plan to protect your next software project, set up your free consultation today!

Request a Consultation