Software Development. Business perspective.

This article is more for a business-related person, than for a technical one.

You are not deeply involved or are not familiar with Software Development, but you are interested in knowing that the basic controls are in place. What questions should you ask your IT? What should you pay attention for?

Here are some key principals in software development domain, which you should be aware of:

• technical debt
• source code repository
• software development life cycle
• requirements analysis
• code review
• testing
• tools
• technology standards
• contribution
• code re-use

Technical debt

It's a an interesting concept, which applies to whole IT, and not only to software development. Many IT people does not use it, because it contains "debt" word, and business people does not pay attention to it, because of the word "technical". There are many definitions of technical debt, but shortly it is an additional interest rate ($$$), you as a company would have to pay in the future, if you implement, develop, or deploy "bad" technical solutions.

Normally an engineer would not want voluntary to increase the technical debt. In many cases it is because the business wants a "quick and dirty" solution. Other cases when the technical debt would be increased we will see below.

The most important factor to reduce the technical debt is to invest enough time into the analysis and the planning phases, before coding.

Source code repository

Developers create added value by developing software solutions, apps, services. And the outputs of their activities is a source code. It's a text. No source code, no solutions, no added value.

So the source code has to be kept centrally and protected. That's your intellectual property.

Software development Life Cycle

SDLC defines the process of how a software solution should be created. Typical steps are:

• software requirement analysis
• software design
• coding
• testing
• code review
• deployment

Good SDLC makes sure that best practices are followed. Some of them are security controls to minimize the vulnerabilities , others are User Acceptance Testing (UAT) to find the bugs before deploying into a production, or Continuous Integration / Deployment to automate some steps.

Requirements analysis

It is a part of SDLC and paramount for a successful software development. A typical simplified example to demonstrate the meaning of good requirements:

Client: I want an apartment.

>>> unfortunately a typical kind of an initial request for developers

Builder: What kind of an apartment? A standalone house? apartment house?

Client: a standalone house.

>>> it's better, but...

Builder: How many rooms?

Client: 4 rooms.

And so on...

The challenge is that without complete (or clear) requirements it is impossible to understand what to build. It's impossible to answer about timelines and costs.

Starting development without clear understanding of requirements would increase your technical debt.

Code review

Though it is a very technical activity, it is of a great importance. It is part of SDLC. The rule is that a developer, who created this particular piece of code, must ask another developer to make the review of changes to make sure that are no bugs, vulnerabilities, and other best practices are in place.

Based on numerous researches it is well know that the costs to reveal and fix bug at this stage could be 10x - 20x times cheaper than at later stages.

Not doing code review would make your technical debt higher.

Testing

It is a part of SDLC. After coding is completed, the final outcomes should be tested. It could be done automatically, and developers have to write tests, and it requires time.

In many cases this stage is skipped. Which lets bugs to move into production. And you already know, that the costs to fix them would be very expensive. Your technical debt will be higher.

Tools

Any professional needs professional tools. Do not save on that.

The most important for software development are:

• Integrated development environment (IDE) is used by developers to do coding and testing.
• Source code repository is used to store and manage source code changes
• Continuous integration and deployment server (CI/CD, Build server) is used to automate some activities (building, testing, deployment) for developers and other IT departments
• Source code security analysis tool

Technology standards

After code review and source code repository "technology standards" is probably the most important concept. There are dozens of technologies, which you could use to achieve the same goal or to develop the same functionality. If you ask a developer which technology is better, then you end up in a kind of "philosophical" or even "religious" discussion. What matters is that each of solutions, which are created in your enterprise, follows the same technological standard.

The key reason for that is that other developers could contribute to your solutions, re-use it, and not re-invent the wheel.

Having no standards, or not following them if they exist, increases your technical debt.

Contribution

A good developer likes to create new things, the things, which are being used. A good developer likes to contribute to other projects. This is the way to grow as a professional.

The contribution is not possible, if

• technology standards are not followed
• there is no centralised source code repositorty
• there is no code review process

Code re-use

That's the essence of efficient software development. You take 3d party libraries and packages and use their features. You do not re-invent the wheel, you do not spend your time developing the same standard features, which are already developed, being used, or being supported.

The same applies to your enterprise.

Not re-using the existing libraries, or not creating them for others to use, would increase your technical debt.

Questions

Now you are familiar with some concepts from software development domain and could ask the following questions to understand the overall situation in your software development department.

1.Do you have a software development cycle?

• The answer "Yes" is not enough. It has to be documented and each developer has to know it by heart.

2.How could you prove that you follow the SDLC?

• You should be able to see the tools, which are used at each step of the SDLC. "No tools" means "NO SDLC".

3.Where do you keep your source code? How often do your developers commit their changes?

• If it is not kept centrally, it's a huge issue!
• If developers do not commit it at least on a daily basis, it's a big problem.

4. Which alternatives to the currently developed or used solution are there? Why have you decided to develop it, instead of re-using the existing one?

In many cases, especially in large enterprises, there are always alternatives somewhere. Re-use them. Contribute to them, if there is no ready feature, which you need.

Overlapping applications is a huge burden for enterprises.

5. Do you follow the enterprise standards, while developing your solutions?

If not, you are hiding the added value from your enterprise. Your solution would be impossible to contribute to.

6. Are Continuous Integration / Deployment (CI/CD) in place?

If not, you are not using the automation capabilities to save time of your developers and other IT employees, so they could spend it on more value added activities.

7. Is source code secure scanning is part of your CI/CD? Do you have and use it at all?

If not, you will be delivering software solutions with bugs and vulnerabilities. And you already know the costs to fix them at this stage. Your technical debt will be higher.

Of course, there is much more behind. Please, share your questions, comments, ideas.