Originally published February 9, 2017, updated Feb. 27, 2019.
Front-end developers work on what the user can see while back-end developers build the infrastructure that supports it.
Both are necessary components for a high-functioning application or website.
It’s not uncommon for companies to get tripped up by the “front-end versus back-end” divide when trying to navigate the development of new software.
After all, there are a growing number of tools on the market aimed at helping developers become more “full stack” oriented, so it’s easy for non-technicians to assume there isn’t a big difference between front-end and back-end specialists.
Front-end and back-end developers do work in tandem to create the systems necessary for an application or website to function properly. However, they have opposite concerns.
The term “front-end” refers to the user interface, while “back-end” means the server, application and database that work behind the scenes to deliver information to the user.
The user enters a request through the interface.
It’s then verified and communicated to the server, which pulls the necessary data from the database and sends it back to the user.
Here’s a closer look at the difference between front-end and back-end development.
What is Front-End Development?
Front-end developers design and construct the user experience elements on the web page or app including buttons, menus, pages, links, graphics and more.
Hypertext Markup Language is the core of a website, providing the overall design and functionality.
The most recent version was released in late 2017 and is known as HTML5.2.
The updated version includes more tools aimed at web application developers as well as adjustments made to improve interoperability.
Cascading style sheets give developers a flexible, precise way to create attractive, interactive website designs.
This event-based language is useful for creating dynamic elements on static HTML web pages.
It allows developers to access elements separate from the main HTML page, as well as respond to server-side events.
These frameworks let developers keep up with the growing demand for enterprise software without sacrificing quality, so they’re earning their place as standard development tools.
One of the main challenges of front-end development – which also goes by the name “client-side development” – is the rapid pace of change in the tools, techniques and technologies used to create the user experience for applications and websites.
The seemingly simple goal of creating a clear, easy-to-follow user interface is difficult due to sometimes widely different mobile device and computer screen resolutions and sizes.
Things get even more complicated when the Internet of Things (IoT) is considered.
Screen size and network connection now have a wider variety, so developers have to balance those concerns when working on their user interfaces.
What is Back-End Development?
The back-end, also called the server side, consists of the server which provides data on request, the application which channels it, and the database which organizes the information.
For example, when a customer browses shoes on a website, they are interacting with the front end.
After they select the item they want, put it in the shopping cart, and authorize the purchase, the information is kept inside the database which resides on the server.
A few days later when the client checks on the status of their delivery, the server pulls the relevant information, updates it with tracking data, and presents it through the front-end.
The core concern of back-end developers is creating applications that can find and deliver data to the front end.
Many of them use reliable enterprise-level databases like Oracle, Teradata, Microsoft SQL Server, IBM DB2, EnterpriseDB and SAP Sybase ASE.
There’s also a number of other popular databases including MySQL, NoSQL and PostgreSQL.
There are a wide variety of frameworks and languages used to code the application, such as Ruby on Rails, Java, C++/C/C#, Python and PHP.
Over the last several years Backend-as-a-Service (BaaS) providers have been maturing into a viable alternative.
They’re especially useful when developing mobile apps and working within a tight schedule.
What is Full-Stack Development?
The development of both the back- and front-end systems has become so specialized, it’s most common for a developer to specialize in only one.
However, at times a custom software development company will have developers who are proficient with both sides, known as a full stack developer.
They powerful team players because they have the breadth of knowledge to see the big picture, letting them suggest ways to optimize the process or remove roadblocks that might be slowing down the system.
Originally published December 7, 2017, updated Feb. 21, 2019.
Scalability is an essential component of enterprise software. Prioritizing it from the start leads to lower maintenance costs, better user experience, and higher agility.
Software design is a balancing act where developers work to create the best product within a client’s time and budget constraints.
There’s no avoiding the necessity of compromise. Tradeoffs must be made in order to meet a project’s requirements, whether those are technical or financial.
Too often, though, companies prioritize cost over scalability or even dismiss its importance entirely. This is unfortunately common in big data initiatives, where scalability issues can sink a promising project.
Scalability isn’t a “bonus feature.” It’s the quality that determines the lifetime value of software, and building with scalability in mind saves both time and money in the long run.
What is Scalability?
A system is considered scalable when it doesn’t need to be redesigned to maintain effective performance during or after a steep increase in workload.
“Workload” could refer to simultaneous users, storage capacity, the maximum number of transactions handled, or anything else that pushes the system past its original capacity.
Scalability isn’t a basic requirement of a program in that unscalable software can run well with limited capacity.
However, it does reflect the ability of the software to grow or change with the user’s demands.
Any software that may expand past its base functions- especially if the business model depends on its growth- should be configured for scalability.
The Benefits of Scalable Software
Scalability has both long- and short-term benefits.
At the outset it lets a company purchase only what they immediately need, not every feature that might be useful down the road.
For example, a company launching a data intelligence pilot program could choose a massive enterprise analytics bundle, or they could start with a solution that just handles the functions they need at first.
A popular choice is a dashboard that pulls in results from their primary data sources and existing enterprise software.
When they grow large enough to use more analytics programs, those data streams can be added into the dashboard instead of forcing the company to juggle multiple visualization programs or build an entirely new system.
Building this way prepares for future growth while creating a leaner product that suits current needs without extra complexity.
It requires a lower up-front financial outlay, too, which is a major consideration for executives worried about the size of big data investments.
Scalability also leaves room for changing priorities. That off-the-shelf analytics bundle could lose relevance as a company shifts to meet the demands of an evolving marketplace.
Choosing scalable solutions protects the initial technology investment. Businesses can continue using the same software for longer because it was designed to be grow along with them.
When it comes time to change, building onto solid, scalable software is considerably less expensive than trying to adapt less agile programs.
There’s also a shorter “ramp up” time to bring new features online than to implement entirely new software.
As a side benefit, staff won’t need much training or persuasion to adopt that upgraded system. They’re already familiar with the interface, so working with the additional features is viewed as a bonus rather than a chore.
The Fallout from Scaling Failures
So, what happens when software isn’t scalable?
In the beginning, the weakness is hard to spot. The workload is light in the early stages of an app. With relatively few simultaneous users there isn’t much demand on the architecture.
When the workload increases, problems arise. The more data stored or simultaneous users the software collects, the more strain is put on the software’s architecture.
Limitations that didn’t seem important in the beginning become a barrier to productivity. Patches may alleviate some of the early issues, but patches add complexity.
Complexity makes diagnosing problems on an on-going basis more tedious (translation: pricier and less effective).
When the software is customer-facing, unreliability increases the potential for churn.
Google found that 61% of users won’t give an app a second chance if they had a bad first experience. 40% go straight to a competitor’s product instead.
Scalability issues aren’t just a rookie mistake made by small companies, either. Even Disney ran into trouble with the original launch of their Applause app, which was meant to give viewers an extra way to interact with favorite Disney shows. The app couldn’t handle the flood of simultaneous streaming video users.
Frustrated fans left negative reviews until the app had a single star in the Google Play store. Disney officials had to take the app down to repair the damage, and the negative publicity was so intense it never went back online.
Some businesses fail to prioritize scalability because they don’t see the immediate utility of it.
Scalability gets pushed aside in favor of speed, shorter development cycles, or lower cost.
There are actually some cases when scalability isn’t a leading priority.
Software that’s meant to be a prototype or low-volume proof of concept won’t become large enough to cause problems.
Likewise, internal software for small companies with a low fixed limit of potential users can set other priorities.
Finally, when ACID compliance is absolutely mandatory scalability takes a backseat to reliability.
As a general rule, though, scalability is easier and less resource-intensive when considered from the beginning.
For one thing, database choice has a huge impact on scalability. Migrating to a new database is expensive and time-consuming. It isn’t something that can be easily done later on.
Principles of Scalability
Several factors affect the overall scalability of software:
Usage measures the number of simultaneous users or connections possible. There shouldn’t be any artificial limits on usage.
Increasing it should be as simple as making more resources available to the software.
Maximum stored data
This is especially relevant for sites featuring a lot of unstructured data: user uploaded content, site reports, and some types of marketing data.
Data science projects fall under this category as well. The amount of data stored by these kinds of content could rise dramatically and unexpectedly.
Whether the maximum stored data can scale quickly depends heavily on database style (SQL vs NoSQL servers), but it’s also critical to pay attention to proper indexing.
Code should be written so that it can be added to or modified without refactoring the old code. Good developers aim to avoid duplication of effort, reducing the overall size and complexity of the codebase.
Applications do grow in size as they evolve, but keeping code clean will minimize the effect and prevent the formation of “spaghetti code”.
Scaling Out Vs Scaling Up
Scaling up (or “vertical scaling”) involves growing by using more advanced or stronger hardware. Disk space or a faster central processing unit (CPU) is used to handle the increased workload.
Scaling up offers better performance than scaling out. Everything is contained in one place, allowing for faster returns and less vulnerability.
The problem with scaling up is that there’s only so much room to grow. Hardware gets more expensive as it becomes more advanced. At a certain point, businesses run up against the law of diminishing returns on buying advanced systems.
It also takes time to implement the new hardware.
Because of these limitations, vertical scaling isn’t the best solutions for software that needs to grow quickly and with little notice.
Scaling out (or “horizontal scaling”) is much more widely used for enterprise purposes.
When scaling out, software grows by using more- not more advanced- hardware and spreading the increased workload across the new infrastructure.
Costs are lower because the extra servers or CPUs can be the same type currently used (or any compatible kind).
Scaling happens faster, too, since nothing has to be imported or rebuilt.
There is a slight tradeoff in speed, however. Horizontally-scaled software is limited by the speed with which the servers can communicate.
The difference isn’t large enough to be noticed by most users, though, and there are tools to help developers minimize the effect. As a result, scaling out is considered a better solution when building scalable applications.
Load balancing software is critical for systems with distributed infrastructure (like horizontally scaled applications).
This software uses an algorithm to spread the workload across servers to ensure no single server gets overwhelmed. It’s an absolute necessity to avoid performance issues.
Scalable software does as much near the client (in the app layer) as possible. Reducing the number of times apps must navigate the heavier traffic near core resources leads to faster speeds and less stress on the servers.
Edge computing is something else to consider. With more applications requiring resource-intensive applications, keeping as much work as possible on the device lowers the impact of low signal areas and network delays.
Cache where possible
Be conscious of security concerns, but caching is a good way to keep from having to perform the same task over and over.
Lead with API
Users connect through a variety of clients, so leading with API that don’t assume a specific client type can serve all of them.
It refers to processes that are separated into discrete steps which don’t need to wait for the previous one to be completed before processing.
For example, a user can be shown a “sent!” notification while the email is still technically processing.
Asynchronous processing removes some of the bottlenecks that affect performance for large-scale software.
Limit concurrent access to limited resources
Don’t duplicate efforts. If more than one request asks for the same calculation from the same resource, let the first finish and just use that result. This adds speed while reducing strain on the system.
Use a scalable database
NoSQL databases tend to be more scalable than SQL. SQL does scale read operations well enough, but when it comes to write operations it conflicts with restrictions meant to enforce ACID principles.
Scaling NoSQL requires less stringent adherence to those principles, so if ACID compliance isn’t a concern a NoSQL database may be the right choice.
Consider PaaS solutions
Platform-as-a-service relieves a lot of scalability issues since the PaaS provider manages scaling. Scaling can be as easy as upgrading the subscription level.
Look into FaaS
Function-as-a-service evolved from PaaS and is very closely related. Serverless computing provides a way to only use the functions that are needed at any given moment, reducing unnecessary demands on the back-end infrastructure.
FaaS is still maturing, but it could be worth looking into as a way to cut operational costs while improving scalability.
Don’t forget about maintenance
Set software up for automated testing and maintenance so that when it grows, the work of maintaining it doesn’t get out of hand.
Build with An Eye to the Future
Prioritizing scalability prepares your business for success. Consider it early, and you’ll reap the benefits in agility when it’s most needed.
Are you looking for software that can grow with your company? Set up a free appointment with one of our developers to talk about where you need to go and how we can get you there!
Wireframes are useful intermediary steps, but they don’t make very exciting presentations when trying to win over clients.
Software like Invision & Indigo Studio are excellent tools for creating interactive, highly visual prototypes.
Highlight a specific user flow to model the product’s main functionality.
Clients should be able to approximate usage closely enough to determine if there are missing steps or features that need to be added.
Resist the urge to get too caught up in design before the client sees the prototype.
Focus on bare functions at first. Have strong visuals, but don’t spend days on custom art assets that may get cut out as requirements are refined.
Only bring the design team in to polish the graphics after the basic functionality is approved.
Allow time for back-and-forth discussion on the prototype. This is the least expensive time to make edits or alterations, so encourage the client to share any concerns.
It’s also a good point to demonstrate additional features or expansions that could improve the final product.
Once the prototype is approved, create a detailed requirements document. List and detail every feature according to the user story.
Don’t just create a sparse feature grid; using visuals to communicate will prevent misunderstandings later on.
After the details are documented, work with the development team to get time and cost estimates for each part of the solution.
Start with broad estimates and work inward. Leave room for flexibility and changing requirements, but don’t pad the estimate unfairly.
Come up with a range where the developer can confidently commit to delivering the project.
Be clear about what the initial estimate covers and how changes would affect the price. Consider including varied tiers to illustrate what can be added later.
All of this leads to the final presentation. This is where the client is given a document which allows them to fully understand what will be built.
Clarity is essential in the decision-making process to approve the project.
Provide full transparency on what it will take to deliver each feature of the final product, and outline details like cost, processes, and schedule.
Good communication gets the project started with a clear vision for what the end deliverable should be.
Earlier phases should have ironed out the majority of issues, so this is essentially a review of everything that came out of the requirements gathering and prototyping phases.
In other words, it’s “reading back the order”.
A final word of warning: don’t rush through the final presentation assuming everyone is on the same page.
This is a developer’s last chance to wow the client and build confidence in their ability to deliver a killer end product. It will either win the client over- or send them looking for another developer.
Concepta takes a detailed, collaborative approach to discovery that’s proven to deliver products that meet our clients’ most pressing business goals. To find out what we can do for you, schedule your free consultation today!
Listen to the client’s initial request, then question further to identify the true source of their pain.
They may think their problem is “our website is outdated and not driving conversions, so we need a new one” when the problem can be better stated as “customers are having trouble finding and using order functions on our old website”.
Be sure to touch on important issues like:
What is the business problem?
What does an ideal solution look like?
What special concerns are relevant to their domain?
Where can the developer add value?
Before moving forward, come up with user stories that help articulate the typical user.
What experience would the client like to create for their own customers? Outline each step in the process.
This will help with the prototype as well as testing later in the process.
Once the first set of requirements are in, it’s time to brainstorm solutions.
Start with what’s already working by researching the “best in class” solutions currently used in the real world.
Note what others in the client’s domain are doing. Evaluate how well or poorly those solutions have worked out.
The goal is not to copy others, but to incorporate the best thinking available into a better solution.
It’s also a great idea to find inspiration outside the client’s direct competitors.
Look at companies who have similar challenges, then bring together the most elegant solutions to assemble a dynamic, enterprise-focused brief.
What comes next?
The bulk of the requirements are collected during these two stages, though the team should be responsive to change within reason as development proceeds.
Now that there’s a good idea of what the client needs, it’s time to visualize a solution by building a prototype of the projected software.
Learn more about how to build the most effective prototype in Part 2 of the Keys to A Killer Discovery series, coming soon. If you want to know more about discovery and how our client-centric development process can help your business, set up a complimentary appointment today!
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
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.
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.
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.
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.
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!
Leonardo Farias, Concepta’s Co-founder and Chief Technology Officer, succeeds Humberto Farias as CEO. Humberto Farias will continue as chairman of the board.
Leo Farias has been part of the Concepta team since founding the company with his partner in 2006. He has an MPS in Business of Art & Design from the Maryland Institute College of Art.
Earlier this year he was recognized with the Orlando Business Journal’s “Innovations in Technology Award”, and the OBJ went on to honor him as one of their “40 Under 40” most influential business leaders of 2018.
The awards are due in part to his active interest in the community and in mentoring young developers.
Leo sits on the advisory committee for the Valencia College Graphic & Interactive Advisory Board, where he helps ensure the curriculum prepares students for real-world tech industry careers.
He shares his experience with other developers at local technology meetups, as well as offering mentorship to entrepreneurs looking to launch their own start-ups.
At heart, though, Leo is a programmer and a problem solver. His technical skills were a major part of building Concepta’s strong foundations.
In the company’s first year of operation they were approached with a major project: find a way to fix an outdated, unscalable piece of software critical to the State of Texas’s emergency response system.
It seemed an impossible task, especially working under the strain of two hurricanes which had struck the state in rapid succession.
Leo didn’t shrink from the challenge. He pulled together the necessary resources to diagnose the problems with the system, find a solution, and put a plan into action that aid FEMA and the State of Texas during their relief efforts.
It was Concepta’s first major contract. Thanks to Leo’s technical guidance, it wasn’t the last.
Concepta has grown from a small start-up into a local leader in technology solutions, with a client list that includes Fortune 500 companies like Disney and Warner Music.
Now, as the company is poised for another surge of growth, Leo’s forward-thinking brand of leadership is more welcome than ever.