Call us to get started at 918-493-7200
Good Code vs. Bad Code

Good Code vs. Bad Code

Managers and executives are becoming increasingly aware of the problem of “Bad Code.” A few relatable questions are: Why are the new features taking so long? Why are we dealing with so many customer issues? Why is the turnover in our IT development group so high? All of these issues can be attributed to bad code, but what is “Bad Code” exactly, and how is it affecting the business? Asking ten developers what bad code is might result in ten different responses. In order to understand how “Bad Code” is affecting a business, the terms “Bad Code” and “Good Code” must be accurately defined.

What’s the Difference? 

The difference between “Good Code” and “Bad Code” can be understood most easily in a comparison. Below is a comparison chart between good coding practices and bad coding.

good code vs bad code seqtek success
The compounding effects of each of these comparisons helps to understand why new features are taking so long, customers are dealing with continual issues, and stress in the IT department is causing low morale and possibly turnover.  In my view from a Software Engineering perspective, I have provided some information below to help understand the comparisons more effectively. 

Easily Understandable vs. Difficult to Follow

Code that is easily understandable allows developers to quickly and accurately make changes to the codebase in order to add new features and resolve customer issues. However, difficult-to-follow code has multiple problems. Bad code makes new features difficult to implement, customer issues are difficult to resolve, and onboarding new developers becomes a lengthy and difficult process.

Logically Separate vs. Inseparable Modules

Logically separated modules allow many developers to work on different aspects of a solution without interfering with each other. However, inseparable interdependent modules make it impossible for developers to make any changes without a comprehensive understanding of the application. This causes longer onboarding for new developers, decreased performance of the dev team in general, and developer dissatisfaction.

Testable vs Untestable Code

Testable code with unit and integration testing is vital to give developers confidence in adding or updating features. Untestable Code lengthens the development cycle by requiring extensive manual testing and regression testing for code change. Fragile tests are sometimes worse than no tests at all because they will require the developer to maintain multiple codebases without any discernible benefit. Tests that have to have extensive rewriting to facilitate any code or business logic change need to be refactored to test modules in a more robust way.

Descriptive vs Arbitrary Names

Descriptive naming conventions add to the readability and maintainability of the code. Arbitrary names cause confusion.  Idx, count, temp, buf, etc. All these names devoid of context are meaningless. A new developer will have the question of what are we indexing or counting? Temporary what or buffer for what?

Well-documented vs Poorly Documented Scripts

Well-documented means appropriate for the situation. If a class or module is very well named and has a clear control, flow documentation can be brief. If it is confusing, difficult or requires extensive domain knowledge, then documentation should reflect the complexity.

Documentation is never a replacement for good architecture and clear code. External APIs and interfaces must be thoroughly documented or there will be ongoing issues with code integration. Poor documentation may still be substantial but can be out of date or trying to cover for poorly designed code.

Up-to-date vs Depreciated External Packages

External packages are very necessary to avoid “reinventing the wheel” on every project. Keeping packages up-to-date and avoiding deprecated APIs is essential to successfully integrating external code into a project. Packages that are ending support or no longer being developed need to be replaced. Out-of-date or deprecated external dependencies will reduce the effectiveness of developers by causing them to spend inordinate amounts of time understanding and debugging code they did not write and for which they are not responsible.

Fixed vs. Flexible Architecture

The architecture of a project is something that does not spring into being fully formed. By necessity, the architecture needs to be flexible to changing business needs and requirements. Refactoring architecture to reduce complexity is essential whenever business logic significantly changes. Ignoring the need to update architecture because of the time required is taking on tech debt that will drown the development team and cause high turnover. No one wants to be responsible for risky architecture changes once the problem has gotten overwhelming.

After looking at some of the comparisons between good and bad code it is clear why good coding practices are so important. As technical debt grows from bad coding practices, feature development slows to a crawl, customer issues become more common and more difficult to resolve, and finding good talent to work on the codebase as well as retaining talent becomes completely unmanageable. Solving this problem is difficult without being able to explain why good coding practices are necessary for a healthy growing company. Pointing out the comparison between good and bad practices allows non-technical stakeholders to see why they must budget time and resources to maintain a good clean codebase, in order to keep new features easy to develop, manage customer satisfaction, and retain talented developers.

-Kenn Williamson, Senior Software Developer, SEQTEK


Why Is Software Development So Difficult?

Why Is Software Development So Difficult?

Technology is everywhere. Software runs devices like phones, vehicles, buildings, manufacturing processes and just about everything in between. Building software is difficult. Writing code isn’t necessarily difficult, although it can have a steep learning curve for new developers. But there is much more to developing software than the coding aspect of it. Three of the many reasons as to why developing and ultimately delivering software is difficult are: a development team misunderstanding the purpose of the software they’re building; the business or customer not knowing what they want (or their own processes); and developers selecting less-than-optimal technologies as opposed to what is best for a particular project.

What is the purpose of software? The purpose of software is to guide and automate processes. It is a crystallization of a workflow into a repeatable action. Why is this important? Because software can’t fix a broken process. People want to use software to “save” a business but this inevitably ends poorly because the software only makes it worse. Software will make a “good” process better by streamlining and simplifying the workflow. Software will make a “bad” process worse by further locking the user or business into poor practices that are counterproductive.

A related problem is that business groups and customers often don’t know what they want. Worse, they often don’t understand what makes their own process function or succeed. A development team is only as good as the requirements communicated to them by the business. Even if the business has a successful process in place, translating that into good software is difficult. Development teams have to sometimes tease the design out of the stakeholders by asking questions and proposing ideas. Stakeholders will have a lot of ideas and it is the job of the development team to winnow those ideas and prioritize them to ensure only those that provide value to the business and its users are completed. The client will often resist this because the priority they place on certain, less valuable ideas is often greater than the particular ideas important in the overall design. Managing expectations and timing as well as prioritizing the most important features first is another reason why building software is so difficult.

It isn’t only the business groups that make the software development process challenging. Developers have their own role to play in the problem. Software developers are people too, and they have strengths and weaknesses. They have technologies they are experienced with and other technologies which may be unknown. This causes many difficulties in creating successful software because often, developers will pick the technology they know rather than the one that would have the most practical benefit to their current design. Of course there is the opposite end of the spectrum where developers will prioritize new and shiny technologies for a problem that can be solved with existing well-established practices as well. Both of these can cause a software project to be deemed a failure without even realizing it until the end.

In conclusion, software development is tough. The problems mentioned above are only some of the considerations that make it so difficult, but they can be overcome. Business groups and customers have to find the development team that will balance their experience with new technologies, help them to discover the optimal design, and fulfill the true purpose of software. They must take a successful business practice and create a software system that allows that practice to work in a repeatable way.

– Kenn Williamson (Senior Software Engineer, SEQTEK)





Hubris Antipattern for Software Development

Hubris Antipattern for Software Development



There is a certain amount of arrogance that exists for someone to believe they can codify a business process they know nothing about in a very short period of time. This is the world of a software developer. Show any software developer a business or job, and they immediately start thinking about how a piece of software can do the work faster, better or cheaper.

Software isn’t magic—it takes jobs that either are or were or could be done by humans and makes them repeatable so that error is reduced or efficiency is increased. More output with less input while not forfeiting quality is how productivity is increased. It was just this combination of computing power, the Internet and software that caused the productivity model of economists to break in the late 1990s.

The definition of hubris is the characteristic of excessive confidence or arrogance, which leads a person to believe that he or she may do no wrong. Hubris is what happens when the excessive confidence of developers careens off into the ditch. Successful businesses are the culmination of a unique set of ideas and talents that fulfill a need of their customers. Over time, successful businesses collect quality people, products and processes, regardless of the software they use. Oftentimes they can become routine and out of date, however we must also remember that successful companies are successful for a reason. Some of the factors of success may be different than many business norms. Software developers must realize and act with the knowledge that the people within the business are the experts (subject matter experts or SMEs) and it is imperative that continual communications with these individuals and groups exist throughout any project. 

Software Development requires a lot of communication. Requirements gathering is what most think of when we discuss software development communications. However, the most important communication is about validating the completion of something. Project delivery is a collection of touchpoints with SMEs correcting a path to completion. Continually demoing software is important to ensure any deviation from a successful delivery is corrected as soon as possible. Communications must also be in the language of the user, which is working code.

Business, technical and management groups must be able to have real conversations without sarcasm, anger, pettiness, etc. The interactions must be healthy, driving the entire process to success. Humility from the software development team is a key characteristic to success. Expectations of completeness and correctness from any information gathered at the beginning of a project without continual communications throughout the project by key SMEs is a recipe for failure. In addition, management must serve developers in every way to add clarity, consistency, remove obstacles, etc. Developers (really all humans) will stop or slow when there is confusion—keeps us from getting eaten—and one the most important jobs of both software development and business management is to eliminate confusion.

An agile project development process embraces this reality and with humility, actively pursues a solution that provides value to its customers. The “Twelve Principles of Agile Software” takes this into account and lays out these principles:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals.
  • Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development.
  • The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity—the art of maximizing the amount of work not done—is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

After 30 years of software development I have found that hubris is the enemy of success and both the SMEs and developers must work together knowing that only through ample communication and teamwork is a successful software development project delivered.


– Hank Haines (CEO of SEQTEK)




3 Challenges That Cause Projects To Fail

3 Challenges That Cause Projects To Fail

68% of companies are more likely to have a marginal project or outright failure than a success (“Study: 68 percent of IT projects fail”).

Budgets are blown up, timelines get dragged out, and the project doesn’t seem to come out like it was originally planned. So why? Over the last 20 years, SEQTEK has been brought into various situations in different industries and here are some of the common issues we’ve seen in software projects.

1. Poor Requirements Gathering

This can be attributed to a number of things. Many leaders assume that developers have the information needed for what the business is looking for. The developers may have an idea of what the business is looking for but they aren’t mind readers. The lack of user input creates miscommunication of the true expectations set ahead. Pair this with poor project management and you can see how this will cause a failed project before it’s even delivered.  

2. Constant Distractions

Most development teams are forced to put out fires from previously flawed projects that they might not have been a part of. This takes their focus off the new project and constantly pulls them back to the older projects. This causes the backlog to build up and it’s a constant back and forth that puts a lot of stress on developers, especially when they can’t dedicate their time to completing the current project’s objectives.

3. Employee Turnover

It’s no secret developers are in high demand and with the average turnover for a software developer around 2 years, projects get shelved if/when certain team members leave the organization. A common reason developers leave is because they become stressed out, overwhelmed and unmotivated. Companies have been left in the dark when a developer leaves the company which often creates a huge knowledge gap and makes it even harder for the next developer to step in and take over.   

The truth is that successfully completing software projects is difficult. You can’t make it easy, however, you can adopt certain processes that are proven to work which allows your team to remove roadblocks quickly and minimize risks. We have worked with leaders in just about every industry and no matter what the industry, these common challenges in software development can create infighting, cause unnecessary stress, waste time, and cause excess spending. To help combat these challenges, make sure your business is properly gathering requirements, have a product owner or project manager that’s responsible for managing those requirements, and give developers the tools and resources they need to be successful.

– Brent Fields (Managing Partner, SEQTEK)

The Importance Of A Product Owner

The Importance Of A Product Owner

When it comes to successful software delivery, the product owner is a crucial part of your scrum team. Scrum is a lightweight yet incredibly powerful framework used in agile software development. As a software consulting agency, always focused on delivering software, SEQTEK utilizes this framework as a basis for its software development process and team structure.

Scrum teams consist of a product owner, scrum master, and the development team (software developers, QA analysts, data scientists, etc.). Most people understand or at least appreciate what the development team does because the members of that group are the ones making the magic. I want to focus on the product owner because while the development team is responsible for building the software the right way, the product owner’s main responsibility is to ensure that the development team is building the right thing.

Software stakeholders on the business side often don’t understand technical jargon, don’t know how to communicate their wants in an easily digestible way to developers, and usually change what they want throughout the duration of a project. This is extremely frustrating for developers, who are not so much concerned with what they are building for the business, just that the thing they’re building works and satisfies what the business tells them. You can probably see how this is a recipe for disaster if the business can’t communicate what they want or changes what they want the development team to build. This is precisely why there is a detrimental gap in some large organizations between what the business expects and what IT actually delivers.

Given SEQTEK’s adoption of the scrum framework and its experience in software projects, we always assign a product owner to our teams, both small and large. The product owner, like I mentioned before, is primarily responsible for ensuring that the development team is building the right thing. There are three main benefits of having a product owner on our teams:

1. The team has one individual they can count on to facilitate communication to/from project stakeholders and the developers.

2. The team has one individual that is responsible for capturing all requirements/wants and prioritizing them so that the team knows they are always working on the most valuable items.

3. The team has one individual whose responsibility is to manage the outcome of the team rather than manage the team itself, which liberates the team to be creative and take risks.

We’ve seen projects fail at various levels because organizations don’t have someone to facilitate the product owner role and we have seen ourselves the advantages of having a product owner on our teams. The benefits of a product owner are seen by the development team and the project stakeholders/users because of the continuous successful delivery that the product owner helps ensure.


– Sam Haines (Product Owner, SEQTEK)