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)

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)

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)

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)