Why Complex Systems Don't Always Equate To Effective Software

There is a misconception that the number of lines or the complexity of code determines the completeness or quality of a system. However, writing code is like writing a novel -  the number of pages doesn't always indicate the quality, style or a cohesive storyline.

In reality, a complex system is often indicative of a flaky system - something that no one wants, especially in the long term.

Software complexity is often the result of legacies, outdated best practices, cowboy developers or a combination of these things. Complexity has more point of failures, exposing more surface area for vulnerabilities and it also puts pressure on those that inherit the system.

Complexity is not a good practice, even though for many it is a state of normality.

Units of Measurement

Under normal circumstances, the productivity of a team is measured based on output. In the physical world, factory workers are measured on the number of items they're able to produce against the hour, a courier drivers' productivity on the number of packages they're able to deliver in a day, and how many orders a fast-food chain can deliver during rush hour.

These are all valid metrics and therefore it may appear that the most seemingly obvious unit of measurement for software is the number of lines produced. But code is much more complicated and less mechanical for traditional methods of productivity measurements to apply. Quality is not synonymous with speed and quantity is not synonymous with the robustness of the final product produced.

So How Do We Measure the Quality of Code?

There is also a misconception that complex systems equate to a good system. However, complex systems are often the precursor to code that's failed to capture your business requirements in an effective, efficient and succinct manner. Code is the act of capturing what your business is trying to achieve and transforming it into a medium that allows for transactions to occur.

Code is the representation and interface between the business and the end-user. If this representation is unnecessarily complicated, then it's not setting your business up for efficiency or the ability to increase your output and pivot velocities.

Therefore, quality code is the software's ability to balance between delivering what the business needs promptly and remain sturdy in terms of code succinctness and overall cohesion.

Rather than the number of lines or the complexity of the code, what should be looked at is how the software satisfies the needs of the business and its capacity to do so in a manner that doesn't overtly frustrate the developer working on the code. Contingent bugs become easier to detect and dealt with - something that complex systems won't allow developers to quickly do.

What Does Quality Code Look Like to a Non-Coder?

It's hard for non-coders to judge the true value and quality of the software being delivered. In part, this is because looking at code is not their domain of expertise.

However, certain language markers communicated by developers are often signifiers of overall code quality. When a developer tells you that the system is complex, what they're saying is that there are a lot, and often too many, points of consideration and potential exposures to failure based on how it's set up and configured.

When a developer tells you that tasks cannot be automated, what they're telling you is that there is too much complexity involved and there are simply too many contingencies. The task of automation will often take more time than to address the issue at the source through a re-write. It often lacks standardization on a code level and fails to capture patterns on a niche and industry level.

What 'Complex' Can Also Mean

The word 'complex' can also be a code word for an over-engineered system. What this means is that the designers, system architects, and developers have designed too many and mostly unnecessary parts into the system to a point where it slows down future deliveries.

Over-engineering often materializes in the form of junk code and branches of features that are so interlinked in a way that cutting out one part has the potential to break the rest of the system. The process of its creation was governed by the thought of future flexibility and features rather than designing to the actual needs of the business.

While the idea of flexibility sounds great, being too flexible can result in a system that has no clear structure or backbone to work against. It becomes like water - you can't easily hold it or do anything in particular with the system that won't somehow break it.

Final Words

The quality of code is hard to measure for managers and those who are not directly involved with the code itself. The number of lines and output should not be the main focus.

There is an emphasis on clean and succinct code in the development community for a reason. In part, it's because the flakiness of complex systems proves to be highly ineffective and detrimental to the business.

So never judge the quality of software based on the number lines. Instead, look at the current speed of the overall feature delivery against past deployments. If the trend is consistent and without major frustrations, then your software is most likely in a good state.

If the trend is slowing down with more complaints, then perhaps it's time to pause and assess where the quality and scalability of your software is at, and what can be done to fix the issues before they become major cracks for your business.

Co-authored by:

Dave Wesley ~ President, SRG

Aphinya Dechalert ~ Marketing Communications, SRG

What Does A Real MVP Look Like?

MVP - or Minimal Viable Product - is a buzzword that was made popular by Eric Ries in his book The Lean Startup. The concept is simple: release as quickly as you can with the minimal required features to get your feedback loop started.

Yet, when we enter into an MVP project, we find ourselves in a sea of unfinished tasks, shifting requirements and developers who simply cannot deliver on time and budget. We get hit with a bad case of scope creep or are forced to release something that is not fit for public use.

So where did it all go wrong? And what does a real MVP look like?

Strip it Back and Strip it Bare

The issue with a lot of MVP attempts is that there is too much required too early on. The point of an MVP release for greenfield applications is so that the foundations are released and more features are added to in a consistent and continuous release cycle.

However, when everything becomes a 'must-have', the point of releasing a minimal product is missed. This can lead you to create a product based on what you think the customer wants, rather than what the customer truly wants.

The point of stripping back your features to create a barebones application is so that you can release quickly to your audience. It prevents your project from being stuck in development for two years, only to find that your market has moved on from the trend.

The feedback loop is missing when you continuously develop but fail to release. Your MVP becomes stuck in limbo and any feedback you get is subjective and internal.

Quality is the Foundation that Sets the Pace for Speed of Future Deliveries

A minimum viable product is more than just a working product - it still needs good habits and foundations in code, infrastructure, and processes to be an effective MVP that is conducive to extensibility and growth.

When an MVP is built with a good base, adding future features becomes easier and faster. When the foundations are weak or have multiple cracks under the pressure of continuous extensions, then the velocity of your application's feature delivery will slow down.

Creating an MVP doesn't mean tacking on features and hope they don't fall off. Rather, it's a process of thoughtfully creating a game plan that is able to adapt to market demands. There is a clear path on where you want to go with the application as a business, but it also has the ability to pivot when necessary if the market requirements change.

Think ‘Minimum Awesome Product’

With the availability of cloud technologies and skilled developers, creating a product that is sub-par will no longer make it in a highly competitive market.

MVP is now synonymous with delivering minimum awesome products that not only take your application back to the bare basics and then build upon it based on the feedback loop or strategic backlog of features, but also delivers a seamless experience that makes your customer want to use your product or service over and over again.

This means interface design that is visually pleasing and intuitive, loading speed that is optimized through the infrastructure based on the geographical location and features that solve a problem.

Types of Features that Make a Product

There are two types of features: the foundational feature and the enhancer feature. When deciding which feature to release, many tend to mistake the enhancer for the foundational feature.

An MVP requires the foundational feature to be decided on and released first before anything else. This foundational piece is also a space for contention and debate, causing the project to shift and delay.

A common strategy to prevent this from occurring is to look at the application, remove the feature and if it still functions without reducing the minimum required user experience, then it's an enhancing feature. If it's a strategic and core requirement, then it's a foundational feature.

There are only so many foundational features in any given application but an endless amount of enhancer features. The ability to distinguish between the two can help prevent your project from running over time and over budget.

Final Thoughts

Not all teams are made equal, and while it is common to assume that everyone hired as a developer has the same quality output, a good team will be able to deliver code that is able to withstand the demands of the codebase growing over time. Without this, your feature delivery cycle will lengthen until it comes to a grinding halt.

When MVP projects start to slip in its ability to deliver, there's a high chance that there are simply too many features to be delivered. Sometimes, it's because the application has grown too complicated in its design for something that's meant to be simple.

A good and effective MVP is one that is simplified with a minimalist approach to product delivery. It is focused on core functionality and user experience, rather than ancillaries that the business guesses that users need.

Co-authored by:

Dave Wesley ~ President, SRG

Aphinya Dechalert ~ Marketing Communications, SRG

What The Cloud Can Do For Your Infrastructure

Currently, cloud computing is synonymous with your business being up to date with technology. However, there’s more to it than just following industry trends. The benefits of a cloud based infrastructure impacts your ability to deliver keystone features, automation, leveraging integrations and drive the cost of running your business down.

Software is like the house you own and your infrastructure is the digital piece of land you rent from cloud providers. This can prove much cheaper in the long term and much more flexible than owning your own infrastructure.

Here is a concise guide on what the cloud can do for your infrastructure, your software and your business costs.

Owning vs Renting

Unlike land, the value of hardware depreciates completely within 5 years. When you build your own infrastructure, the capital used to purchase hardware becomes an instant sunk cost. While the same could be said for Cloud based infrastructure, when you leverage Infrastructure as a Service (IaaS), the final total cost is often significantly smaller.

This is because with IaaS, you are often getting charged per hour or charged per 100k to 1 million calls to an instance. The cost itself is usually cents per hour, with free tiers for set up trials and experimentation. With major players like Amazon, Google and Microsoft’s Azure competing with each other on price and available services, your business is constantly open to potential opportunities in cost structure innovations and services available.

With the rise of micro services, hybrid solutions and automation, IaaS providers also give your software the ability to be constructed in a manner that leverages these cost savings further while eliminating the need for upfront hardware capital investment, ongoing operational expenses and indirect costs such as downtime and unscheduled offline services.

What it Means for your Developers

When developers have access to infrastructure and are given the ability to create as needed, you are able to leverage the DevOps role more effectively. Agile teams are often cross functional teams with members being experts in more than one area.

This enables developers to think about the software they’re creating for you as part of a whole, rather than just code in isolation. It lets them think about things like maximum socket connections to databases, how to leverage micro service structures and any other services that the IaaS provider has.

When developers are able to leverage services offered by the infrastructure provider, they are able to increase the efficiency of their workflow through automation and integration of deployment processes, staging for different scenarios and code auditing sessions.

Elastic Infrastructure to Cater to your Growth Demands

The cost effectiveness of IaaS is not just limited to positive and a much lowered cost to your overall IT budget, but also your software’s ability to scale based on demand.

Elasticity of availability is baked into how IaaS works and is often one of the main factors for business’ usage of cloud. Cloud providers are now also providing tools such as integrated reporting, the ability to create complex but cost effective systems using best hardware management systems that your business doesn’t have to worry about. Availability zones across different countries can also enhance your business’ delivery and responses based on customer target groups.

For example, if your business originally served US based customers but want to also expand to the Australian market, cloning your current infrastructure to a IaaS center in the Pacific Ocean region will result in better response time than a US based IaaS center.


Growth is the ability for a business to adapt to market requirements quickly and efficiently, and a well structured cloud solution often allows for software to leverage cross distribution and maximize its potential usage. The ability for automated scaling can also mean that your business has the opportunity to capture customers that would not have been catered to in instances where there is an unexpected spike in usage. 

The cost of owning your infrastructure can be a massive hit to your budget when it comes time to upgrade. If your business runs on this model, shifting to a cloud based solution can give your software the flexibility and elasticity it needs to adapt to your market demands and needs.

Co-authored by:

Dave Wesley ~ President, SRG

Aphinya Dechalert ~ Marketing Communications, SRG

How Good Interface Design Can Make Your Teams More Productive

There was a time when shades of grey was an acceptable design choice when it came to custom software development. They remind us of a time when there was no such thing as auto-fill, intuitive design practices and color schemes that made cognitive and psychological sense. 

However, many businesses still use these interfaces on a day to day basis — in part because they’ve yet to update their software or migrate out of the current system. While the software may work perfectly fine, bad interface design does more harm than good to the person behind the screen.

Here are some reasons how and why.

Factors that Increase Friction

Software is the act of digitizing systems. If the interface is inefficient, then the system is inefficient as it is a major piece of your process workflow.

However, inefficiencies caused by the interface often share a certain number of characteristics such as lack of clear process pathways, too much “thinking” required in order to proceed to the next step, inaccessibility due to reduced visibility of important elements and entry of data in an order that is “unnatural” to the way work is actually performed.

Your data can also become prone to errors if there isn’t enough validation attached to your interfaces or not useful error handling for the user. Humans are prone to errors but good interface design prevents this from happening through predetermined error handling and expected inputs, thus reducing potential for errors in the long run. 

The Impact of Efficient Design

There’s a lot of focus on interface design when there are customers involved. Tracking, analysis, heat maps and A/B testing are some of the common methods to enhance a user’s experience. However, when it comes to internally used software, interface design becomes secondary to almost everything else.

But your team members are customers too. The difference between internal and external customers is that your team doesn’t have a choice of potential alternatives. For an external customer, if your system is hard to use because of how the interface is designed, there’s a higher chance of brand abandonment. For an internal customer, this can result in process abandonment.

Friction caused by design reduces overall productivity because it takes longer to complete a task. An additional click here, an additional click there with no clear flow of information design may seem like a minor thing, but if a team member takes an additional 1-2 minutes for a minor task that is performed over a hundred times each day, this can lead to over an hour of lost potential productivity. 

Creating Seamless Workflow Processes

Software is a tool that is used by employees to perform their day to day tasks. From booking systems to looking up data for a specific use case, software is an undeniable and integral part of the workplace.

When productivity hinges on someone’s ability to complete a task, bad interface design can end up being the bottleneck to your workflow and processes. A seamless experience is when technology works like a natural extension to the task rather than a disruption due to a person’s inability to quickly locate or do what they need.


Regardless of how the backend is structured, good interface design can enhance your team’s performance of their daily tasks and therefore increase their overall productivity. 

Front end design is important because it is the first point of contact anyone has of your systems. Inefficient interface design is akin to a broken system. While the backend and infrastructure may be solid in its construction, a weak front end lets down the software as a whole — as well as your team’s ability to effectively do their job.

Co-authored by:

Dave Wesley ~ President, SRG

Aphinya Dechalert ~ Marketing Communications, SRG

Why You Need To Transition Your Legacy System Out And Into The Future

Everything ages — some more gracefully than others. Software and systems are no different. While it may work, the declining user experience can impact your business negatively. It can cause forced inefficiencies in your staff, reduce your ability to pivot your business and slow your day to day processes down into a grinding mode of constant frustration.

But why upgrade when everything still works? You could almost ask the same question for your clunky 15 inch TV from the 90s.

Don’t let Legacy Systems Kill your Advantage

Startups are popping up everywhere with the latest tech stacks and abilities to quickly implement features and pivot their strategies. However, established businesses have something startups do not — market recognition, prestige and an existing customer base.

But these advantages could be lost due to the upkeep of a legacy system. 

As new methodologies of software creation, iterations and cycles become mainstream, the older and legacy software built in a different era becomes obsolete. Speed becomes a major problem, along with usability and user experience — creating a disadvantage for your business.

This in turn becomes the Achilles heel of your operational processes. Startups and businesses that have opted to upgrade their system lessen this potentially crippling issue through newer tech stacks. 

An Efficient System Makes for Effective Staff

Software and digital systems are tools that employees use in order to complete the tasks that make up their work. When the tools are inefficient, there is a flow on effect on your staff’s maximum efficiency and productivity potential. 

The long term costs of inefficient staff is often more than the initial investment of upgrading your legacy systems. While the cost of upgrade and maintenance is quantifiable, inefficient and ineffective staff due to your current systems can impact negatively on your brand and market standing, in conjunction with time lost trying to battle with your current clunky digital platforms. 

A skilled staff’s potential then becomes underutilized and their ineffectiveness in performing their tasks can add to an overall sense of frustration and long term job dissatisfaction.

Faster Response to Market Demands

When you own a legacy system, the pool of talent available for feature implementation is also much smaller. This limits your business’s ability to pivot to market demand, making you slow to adapt to the needs of your customers. 

It also means that you are slow to leverage new technologies, limiting the potentially impacting strategies that can contribute towards achieving your business’s vision. 

Not only that, adding to a legacy system, rather than migration out, can negatively impact your investments as you are essentially adding to a sunk cost that’s potentially running past it’s used by date. When you’re adding to an old system that’s no longer effective, it’s like doing upgrades on a car that’s already got high mileage. 


Legacy software and systems don’t impact just the business. It impacts the people using the system, including, but not limited to staff, external users, report consumers and the customers.

While software and systems don’t have an explicit expiry date, this can still be felt through its performance, ability to fulfill your business’s needs and support your company’s ongoing strategies and vision effectively.

When one or more of these areas are not met, it’s usually a sign for an upgrade. Startups often have the advantage of speed and ability to pivot their strategies because they are not tied down by legacy systems and software. Established businesses, however, face a different and potentially crippling issue that needs to be addressed. 

Co-authored by:

Dave Wesley ~ President, SRG

Aphinya Dechalert ~ Marketing Communications, SRG

Why Portugal Should Be Your Next Software Development Destination

When we talk about off-shore, no-shore and remote software development, we often associate it with Asian countries such as China, India or freelance developers working from incubation hubs and cafes in Thailand or Malaysia. However, a rising star in the south western borders of Europe sits a seemingly quiet little country known as Portugal.

With the allure of fine wine, beaches and Spanish influenced architecture, Portugal is a rapidly growing economy with a labor force that still sits under the radar on the exchange rate, a smaller time zone gap and good English skills — the last being something that can help determine project requirements comprehension and quality of delivery. 

Educated Tech Workers

Apart from being a great tourist destination, it also hosts the Web Summit — the latest tech conference in the world. Yet Portugal continues to fly under the radar as a software development hub for those looking to hire off-shore. 

According to the SEP Monitor Report, Portugal’s tech industry is growing twice as fast as the European average. In part, this is driven by the growing number of external companies looking to Portugal for it’s software development and platform integrations. 

The OECD Indicators reports that approximately 100,000 students graduate each year from the eight Universities available in the country, with up to 21% opting for study areas in science, engineering and mathematics related fields. This in turn fuels the growth of the country’s young and highly qualified talent pool. 

Right in the Middle 

The country’s geographical location is also fueling the tech industry’s growth for off-shore work. In contrast to alternative off-shore hubs in Asia, Portugal’s physical location makes it ideal for businesses to hire developers outside of the United States. 

Sitting in the same time zone as London, Portugal is an hour behind Central European Time and only five hours ahead of New York — making it convenient for communication and online conferences.

While Portuguese is the official language of Portugal, English ranks second as the major language, especially in tourist areas such as Lisbon. English is also taught in schools as a second language and is gaining in popularity among youths. 

Same Quality for Less

In conjunction with the massive pool of software engineering talent available, Portugal’s tech scene is starting to catch the attention of startups who are looking to increase the efficiency of how their budgets are being spent.

Five and a half years ago, Sursumcorda Resource Group (SRG)  was one of the first US based companies to recognize the benefits of an external development team. As a result, we became one of the first people to establish as a no-shore software development company, helping businesses connect with the local Portuguese talent. 

With an established network of quality developers and energetic talent, SRG is thriving with a Portuguese tech team. By specializing in areas such as healthcare platform development and integration, we are able to effectively provide clients with quality solutions. 


Portugal is fast becoming a desirable alternative in the off-shore software development scene due to their reliability in product quality. Costs, time zones and communication proficiency also add to the list of additional desirable qualities. Beautiful beaches, good wine and a wide range of foods are perks, as well. 

With SRG being an established no-shore, out of house company means that we are skilled in our ability to coordinate and communicate efficiently, making the no-shore experience feel seamless and borderless. Effective agile delivery thus becomes possible due to team members being familiar with each other and working like a well oiled machine.

For these reasons, startups and businesses should look beyond their local hires and popular overseas markets. Perhaps it’s time to look somewhere outside but a little bit closer to home. 

Co-authored by:

Dave Wesley ~ President, SRG

Aphinya Dechalert ~ Marketing Communications, SRG

Why Smaller Quality Teams Matter

There is a misconception that the more people you have working on a project, the faster it will move off the ground. However, more isn’t always better and there is a point of no-impact and diminishing returns once a team reaches a certain size.

Why quality matters

When a project’s budget is focused on the quantity of developers rather than quality, the long term value and stability of the software is often impacted in an inverse manner. The project’s final delivery is only as good as the developers behind the code. 

Quantity does not equate to, nor does it guarantee quality as there are different calibers of developers available. An effective developer can often accomplish a coding task in a third of the time and at a higher standard than a sup-par developer who may appear initially cheaper by the hour. Cost effectiveness of your investment often materializes in the form of good and solid software rather than what you originally spent. The stability of the code produced also determines the long term costs, maintenance and price of future extensions and upgrades. 

Smaller teams makes better agile teams

When it comes to software and agile delivery, sprints are most effective when the amount of communication required is reduced. A small core team of developers is much better and easier to coordinate than large teams with varying levels of skill. With smaller teams, quality assurance across the code base becomes a much simpler task. When less people are working on the same code, the amount of potential code conflicts is often significantly reduced. Errors and misunderstanding is minimized as smaller teams are much better at communicating with one another. 

For an efficient and high quality piece of software, everyone working on the project needs to keep in sync. When there are more people on the team, each team member ends up spending more time working on communication rather than actual work, resulting in reduced overall output. If communication is not maintained, delays often occur as code bottlenecks and misinterpretations arises. This is known as the Ringelmann Effect - where the productivity of individual members reduces significantly as the size of the group increases, resulting in less value for the total money spent. 

Bigger isn’t always better

According to a study done by QSM, the difference between projects with approximately 10,000 lines of equivalent source code for large and small teams is barely a week, with large teams averaging 32 developers and small teams being 4 people. Not only that, the defect rate for large teams was five times greater than small teams. Code defects and bugs are unavoidable and it requires time for the discovery process, documentation and fixing. This often results in unnecessary inflated costs financially and the project’s schedule delivery. 

For faster and leaner development, more people in a team often results in the opposite effect. 

When it comes to an agile no-shore or non-inhouse approach, a small team of 8 people is easier to pivot than a large group of 40 developers across multiple time-zones. Smaller teams often result in simpler processes with less cross-team dependencies. While code management tools like Git and methodologies like agile don’t specify team size, smaller teams are most effective for these tools due to its nature to streamline and simplify. 


While the idea of increasing manpower to increase output works well in most manufacturing scenarios, your software and infrastructure is much more complex than well defined processes that can be replicated mechanically. Creating software is the process of transforming business requirements into tangible digital products. 

More minds working on the task doesn’t necessarily guarantee that the project’s velocity will increase. Creating a strong team of developers who are able to effectively communicate with each other is a better way of coding software that is able to perform and support your business. 

Co-authored by:

Dave Wesley ~ President, SRG

Aphinya Dechalert ~ Marketing Communications, SRG