How Software Development has changed in the Past Decade

When we consider the dramatic ways technology has improved over the past decade, our first inclination is to think of hardware or the Internet. However, software development has changed just as dramatically as all other aspects of technology. The fact is that we approach software development much differently than we did a decade ago. That is because the world has dramatically changed since a decade ago.

Software development is a highly complex process and requires a team to build it correctly. A programmer doesn’t just sit down and write code to create an envisioned application. For many years, the creation of a software application was approached, much like the manufacturing of an automobile. The project phases traditionally were planning, design, architecture, development, testing, and release. Once launched, the support and maintenance phases started as application developers then repeated the entire process to create version 2.X and so forth. It was typical for the period between planning and product launch to exceed a year or more. This elongated process is outdated today in a world of digital transformation that demands total agility and responsiveness.

Below we have outlined some of the significant changes witnessed in software development over the past decade. It is essential to realize these changes and understand why the traditional approach to development is no longer applicable today.

 

Faster Deployments through Virtualization and Containers

It is hard to believe that a decade ago, many organizations still relied on physical servers to host applications. Each physical server hosted a single app. Physical servers proved extremely costly due to inefficient resource utilization. Then to compound the problems of a single point of failure, there were expensive hardware redundancy architecture, time-consuming upgrades. As you can tell, let’s just say it was far from an ideal situation.

Then, came virtualization and the software development world suddenly sped up. A single server can now host a multitude of virtual machines, thus maximizing resource utilization. Virtual machines are then members of large server farms that enforce automated redundancy. Virtualization began reducing server deployment from months to minutes. Reducing the implementation time for application host structure reduces software deployment time as well. This lead to the natural transition to containers and microservices. The introduction of containers further isolated applications from their hosted environments. Each container hosts all of the external dependencies required by its contained application. This dramatically increases flexibility as containers can be migrated amongst different hosting platforms and sites. It also simplifies API development for programmers in a platform-neutral environment.

 

The Expansion of Audiences and Platforms 

Fifteen years go, the majority of applications were business or productivity based. In the past decade, we have witnessed the prominent rise of the consumer app. Follow that by the proliferation of mobile devices that launched an insatiable appetite for these new apps. Applications are not just for desktops anymore, and the client-server application model no longer restricted to only PCs. The app is now the communicative epicenter that companies use to interact with their customers. In order to satisfy this need, applications are now released to accommodate a multitude of computing device platforms.

 

The Scalability and Flexibility of the Cloud

The demand for browser-based and mobile apps has skyrocketed in the past decade due to the consumerization of IT. This has stimulated expanded distribution channels in which consumers can access app stores to download apps on-demand in real-time. This scope of scalability is only available in the cloud. The cloud certainly was the gamechanger that launched the app revolution. What’s more, containers and virtual machines can be easily migrated to demand between on-premise and cloud environments. The availability of cloud services has completely changed the way that developers provision, build, and deploy applications and the external dependencies they require.

 

DevOps and Agile Methodology Impact on Software Development

The culmination of the velocity of deployment, the high demand for new apps, and a seemingly limitless audience and distribution network demanded a new approach to software development. Innovation can no longer wait for the traditional waterfall approach to software development in which each subsequent phase of the development process must wait for its predecessor. Instead, a new holistic approach was necessary to encourage communication, collaboration amongst software operators and developers. A new agile development process was adapted greatly accelerated the development pace to accommodate faster releases and improve the quality of code releases. A new DevOps method was incorporated, in which qualitative assurance was incorporated as automated progressions into the entire development process. Thanks to DevOps and Agile management practices, speed and quality are now amalgamated into a single expectation level.

 

Third-Party Software Developers

In the same way that developers utilize third-party software components to increase the speed and quality of development, companies are turning to third-party development teams for the same reasons. It is challenging to retain the high-level talent required to create multi-platform applications at the velocity required today. Technology drives innovation today. Bringing in third-party developers that have a wide array of technical skills and experience can bring much-needed expertise and innovation. That can not only overcome impending challenges but inject added value as well. Our other recent blog talks about the importance of injecting third-party developers to your team. 

Let Xcelacore show you how we continue to assist companies in adapting and excelling to not only the change witnessed over the previous decade but the impending breakthroughs of tomorrow as well.

 

Let’s start out by saying that it’s good to have a choice because many companies are strictly limited to purchasing third party software.  You’re in a prodigious position if you’re weighing whether to finance a customized software solution or purchase one off-the-shelf. There are advantages and drawbacks to either approach.  Oftentimes the debate involves determining the right balance between control versus cost and immediate needs versus long-term opportunities. 

Easy Considerations

If you fall into one of the following scenarios, then the choice is already made for you.

  • The software you need doesn’t yet exist

Its perfectly feasible that the particular solution you need is not yet available on the market.  If this is the case, then you need to build it.

  • You need the software ASAP

If you need a software solution implemented in less than thirty days, then you can stop reading and find a vendor that produces something close to what you need.

  • Your industry or organization is in a highly regulated field

Industries such as financial services are required to use software solutions that have been rigorously tested and vetted in order to meet compliance regulations.  Unless you are a large corporation, chances are you will be better off purchasing.

With that out of the way, let’s look at the advantages and disadvantages of buying an existing solution. 

Advantages of Buying Software

The primary advantage of purchasing Commercial-off-the-Shelf (COTS) software is that it is a known factor.  Whether it’s a fixed or variable cost, the initial price is known or can be calculated up front.  Implementation and deployment is much faster than building.  In addition to the software, your purchase usually entitles you to product guidance, expertise and support from the vendor as well.  This is an important consideration particularly when things go wrong or you need access to a knowledge base for advice.  Finally, bugs are discovered early and often because the software is continually being tested by the other customers.  Bugs are found before they affect your own organization. 

Disadvantages of Buying Software

Innovation

It may sound like an oxymoron, but one big disadvantage to buying software off-the-shelf is the uncertainty of the future.  While the purchased software may satisfy your requirements today, your needs will undoubtedly change in the future.  As a result, you may outgrow your software.  There are also some important questions to ponder. How certain are you that this particular software vendor will be around in five years?  How reliable is the company that you are purchasing from? Will the company continue to innovate and upgrade the software with new technology and features or will they go out of business?  After all, 96 percent of businesses fail within 10 years.  These are key questions to ask because switching between software solutions is an expensive proposition. 

Security

Security is another major consideration as third and fourth-party data breaches have dominated the headlines over the years.  Third-party data breaches over a 12-month period increased from 34 percent to 45 percent in 2018 according to a report by The Ponemon Institute.

Feature Mismatch

While buying is nearly always cheaper up front, you will undoubtedly be paying for features that are not relevant to your particular industry or company.  Similarly, the software is likely to be lacking in capabilities that you wish you had.

Now let’s look at the advantages and disadvantages of creating your own customized software solution.

Advantages of Building Custom Software

Feature Match

The primary advantage of building your own software is that it ensures that you get what you want because you are in charge.  Think of the difference between having your next home custom built from the ground up vs. buying a resale.  The development team creating your software will do so based upon your specific requirements. This ensures your software solution delivers all of the features you want and need

Innovation

What’s more, the innovation process never has to end when you’re building.  Custom software can be modified in real-time, and new features and capabilities can be introduced as needed. As your business changes, so too can the software. You won’t have to wait for a vendor to develop specific feature sets to suit your business requirements – you can develop and implement them as you go. 

Scale

Another advantage to building custom software is that it can grow alongside the growth of your organization and at your own pace.

Competitive Advantage

Custom software can also offer a competitive advantage over your competitors by leveraging the technology that is better suited for your company and your customers. This advantage is even more pronounced if your competitors are operating canned off-the-shelf software. 

Disadvantages of Building Custom Software

Time

The primary disadvantages are time and cost.  Obviously, implementation takes much longer and unanticipated delays can prolong the process even further.  

Cost

While some organizations may have an internal development staff, chances are you will have to hire an outside development team to partner with.  Knowing an exact upfront price for a custom software build project is highly difficult.  The only thing to be certain of is that it will most likely cost more than purchasing COTS software.  While the initial cost may be greater however, custom software can prove less costly in the long run due to the negated risk of switching software solutions as well as the appreciated gains of greater productivity and efficiency. 

The Final Choice is Up to You

There is no clear right or wrong answer when it comes to the question of buy versus build. It depends on your business, your requirements and your resources. Your best option is to choose based upon your particular situation and needs.  A simple equation to remember is that more control equates to greater cost; and lower upfront costs will garner you less control. No matter which path you decide upon, be sure to do your research in order to find a vendor or development team that can provide the solution that best fits with your organization’s requirements.   

Ready to Talk? Contact Us.

You need a software application that does (blank), you meet with the developers, and a few months later you have your new software. Easy, right?  If only it were that simple.

Most people agree, creating customized software is generally a complex process. It requires a great deal of planning, collaboration, teamwork and management. And the stakes are high. A poorly implemented software release paints a negative image of the development team as well as the organization that hired them.  That’s why the software development lifecycle requires some type of methodology to oversee the development operation.

There are two primary methodologies you should be aware of – Waterfall and Agile.  A quick web search will garner numerous links in which these two approaches duke it out as to which one is better.  However, to say one is better than the other is like saying that owning a truck is better than owning a compact car. If you need to haul a lot of stuff, a truck is better.  If you live in a very dense, urban area where parking is at a minimum, a compact car is better. The approach you choose depends on the situation at hand. Not sure which approach is best for your project? Read through the descriptions of each below to understand each one. Still have questions – feel free to reach out to us and we’ll help you decide.

Waterfall

First off, waterfall may seem like a strange name for a project management process – but it’s a common term in IT;  and many refer to it as “traditional.”  One possible way to explain the name is that just like a waterfall, water can’t go back up after it cascades downward. A waterfall project is comprised of various stages and each one must be completed and signed off on before being passed on to the subsequent stage.  Each successive stage has its own personnel team and relies on information forwarded from the previous stage. Waterfall is ideally suited for instances in which there is a defined vision by the customer of what they want. To use an antiquated example, think of Henry Ford and the Model T.  The car moves along the assembly line as teams of employees complete their assigned tasks. What starts out as a simple frame in the beginning, drives out of the factory a completed car, ready to hand off to the dealer. Using a waterfall approach, the car moves along from start to finish in order.

In terms of a software development project, the successive phases are usually broken down into these basic stages:

Research – Analysis – Design – Construction – Testing – Implementation

A waterfall-oriented development team usually consists of four roles that include a project manager, business analyst, developer and tester.  Compared to agile, waterfall puts more emphasis on planning on the front-end. Progress is easy to measure and end results are more predictable thanks to detailed planning and design in the early stages.  You could say that waterfall sticks to the script as the plan is conceived at the beginning and everyone follows the plan in proper order.

Agile

As its name implies, this methodology is about agility and flexibility.  It’s highly suited for software development due to software’s elastic nature. Unlike, waterfall, there is a more loosely defined vision that guides the process. There are no defined stages.  Agile is a continuous deployment practice made up of “sprints.” A sprint is a short span (2-3 weeks per sprint is very standard) in which products are planned, developed, reviewed and released.  But the definition of “product” can vary from project to project. Agile isn’t designed around a single release, but multiple releases, that may in fact induce further releases.

For instance, the sprint at hand may be to create a button that the stakeholders of the application have decided is now needed.  Once completed, this sprint may then be followed by another sprint that centers around the release of a new application feature. This perpetual cycle can go on for years as the software evolves.  Each sprint is loosely defined by a storyteller who creates a story of what the product at hand should accomplish based upon the input of the stakeholders. Because there is no highly defined plan at the beginning, each day begins with a daily standup, a fifteen-minute meeting in which contributors and managers discuss what was completed the previous day and agree on what needs to be done on that day.

Although the agile approach may sound chaotic, it is actually a very orderly process that allows for constant customization and refinement.  While the end product may be far different than its vision, the customer and other stakeholders are continuously involved throughout the agile process.  One of the goals of Agile is to get something of value in the hands of the customer as soon as possible. In the case of a new application, the aim of the agile team is to get a basic working application delivered as soon as possible.  Continuous sprints then take place to add new features, many of which may have never been conceived at the outset. Unlike waterfall where testing is done at the finale, testing is continuous, sometimes operating in parallel to the code development.

Summary

As you can see, each approach is very different.  While Agile is definitely the newer methodology of the two, it is readily gaining acceptance in the software community.  Both approaches have their advantages and disadvantages. As stated, there is no overall better way, only a way that is better suited to the needs of your project and organization.  Before you begin a project, be sure to find out which approach your development team utilizes.