Big news! Over the last few months, we’ve invested a lot of time and energy into building a new visual identity. We’re very happy with the results and are confident you will be too. We’re excited to share this update and why we’ve done it.
Now to officially announce, Concepta has gone through a rebrand!
We’ve released a new brand identity, which includes the changing of our logo, typography, colors, imagery, messaging and website. It’s a lot bolder, simpler, and more modern.
Our old logo was a blue solid cube inside of a larger, transparent cube. It symbolized what our solutions are…a building block and the missing piece that many enterprise companies were looking for.
Our new logo shows an arrow pointing upwards. If you look closely though and allow your eyes to create the rest of the outline, you’ll see a hint of the cube’s existence. Our designer used techniques such as 3D, shadowing, and use of lines to give the design a field of depth. The rebrand represents us evolving, moving forward, and helping our clients discover the missing piece to disrupt their industries.
The new messaging is all about evolving and movingforward. Being stuck is not an option. Everything in our lives is the result of advancement. Concepta was built 13 years ago and as new trends and developments become standardized, we continue to move forward so we’re not left behind, and neither will our clients.
In the rebranding process, we wanted to leave some things untouched. Our services, values, level of service, quality of delivery, and our people have remained the same.
Concepta services are still the same but now fall under three main categories: Product Development, Technology & Engineering, and Strategy & Growth. This is packaged in a way that makes it easier to understand what we do.
We are making our process now more pronounced. We live and breathe the agile methodology and it’s only fair to share how we make things happen here. Not only does our development team utilize this method, our entire company, including the operations team (sales, marketing, finance, project management) are on board too.
Our values are based on 5 pillars: excellence, passion, commitment, integrity, leadership, and teamwork. Through these, we are able to deliver quality work that takes only weeks, not years.
Why rebrand now?
Times have changed. We aren’t the same company that we were 10 years ago, 3 years ago, or even last year. We’ve evolved.
Concepta CEO, Leo Farias, says it best: “As a company we have grown and the quality of work has continued to increase. It’s important that everything we do displays our values and level of quality we deliver.”
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!
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!