Table of Contents

• Introduction
• 1. Advantages of process
• 1. Work organization/specialization:
• 4. Usage of open source libraries:
• 7. Sharing solutions:
• 2. How avoiding process affects companies!
• 2. Non-extendable/Non-maintainable code:
• 5. Late deliveries:
• Summary
• Next Steps

Introduction

Continuing our series about applying process in software development, in this article we’re going to elaborate how applying process would impact positively the software and the team structure. If you don’t have an idea of what i’m talking about, please refer to my first article SDLC in practice: practical definition.

1. Advantages of process

1. Work organization/specialization:

• Every modification on the software should pass through multiple phases.
  • all the changes are organized and visible to all team members.
• Everyone’s work is tracked, so there is no chance of blaming between team members when some problem arises.
  • leads to a better communication and cooperation between team members.
• The tasks are assigned based on the specialty of each member in the team.
  • division of work
  • more quality job

2. Documentation

• Any team member is able to understand the business of the software through just reading the specification document without the need of the back and forth interactions with the experienced team members.
  • saves much time for him and them
• A developer is able to refer to a design document whenever he faces any difficulty in understanding some component/module or even the whole architecture of the system.
  • saves too much time for him instead of reading code and trying to find out by himself
• New comers would not face problems to ramp up to the system, they refer to the specification document in order to understand the business, and refer to design document to understand the technical architecture.
  • no more too much time lost by the members in ramping up a new comer

3. Maintainable/Extendable code:

• Every change on the software passes through multiple design/code review phases.
  • this results in applying best practices and adapting best design principles, hence an extendable software in the future.
• One of the best coding conventions is documentation, classes/methods/blocks should be documented, companies who apply process don’t allow undocumented code to be published.
  • this results in a code which can be understood by human, hence maintainable in the future.

4. Usage of open source libraries:

• One of the best advantages of process is that developers tend to research and think of the best possible solutions because they know that more experienced members will review their code.
  • more research would lead to more investigation of new libraries and technologies, hence using efficient and stable libraries instead of reinventing the wheel.

5. Code repository:

• Every modification on the software is finally checked in inside the repository system, so that all modification versions are tracked and available upon request.
  • developers are able to rollback to any older version whenever they want
• Developers are able to keep track of the changes they do when doing any modification on the system.
  • they would easily package the changes instead of manually keeping track of every single changed file.
• If you find yourself stuck at some piece of code and don’t know how it works, you’re able to find out through the code repository who implements this code and you can refer directly to him without losing time on understanding the code.
• Source code is never lost.

6. Low regressions:

• Due to code repository, the latest version is always synced with the one deployed on production servers, so developers could just deploy their changes on the production server without any fear of corrupting already working features. (Absolutely, changes should be tested very well on local and test environments before publishing).

7. Sharing solutions:

• Any design or code change is discussed between team members so that would open a door for sharing experiences and knowledge.

2. How avoiding process affects companies!

Some companies only focus on delivering a working product at a specific time frame regardless of the code quality, so here below i mention the basic problems that these companies normally face:

1. Lacking documentation:

• When a new comer joins the company, he won’t find any business or technical documentation about the product that he’ll be working on. The only way he would understand the product is through practicing on it and wasting other member’s time with a lot of back and forth interactions. And he will most probably end his ramp up period without understanding well the basic business and architecture of the system.
• Most of the time developers would find themselves reinventing the wheel and implementing features that already exist in the product API, that’s because no one even knows that they really exist.
• In case of legacy product where all the developers who write the architecture left the company, team members couldn’t be able to understand the architecture and the different components of the product without putting a lot of time on reading code and investigating by themselves.

2. Non-extendable/Non-maintainable code:

• Since there is no design/code review phase in the development cycle, every developer can implement his task with the way he wants, so this results in a very hard maintainable code..
• Lot of unused and wrong-named classes/methods/variables.
• Lot of complex algorithms which can’t be even understood.
• Lot of coupling and dependency between system components.
• Lack of coding standards/conventions, design principles and open source libraries.

3. Clients concerns:

• Clients suffer a lot from regressions which appear after deploying any new feature on the production server, because the non-maintainable code is always open for regressions.
• Clients complain about the slowness of the system and always ask for performance improvement.

4. Lost code

• Due to non-existence of process, developers would fix urgent bugs directly on the production servers, so there is a big possibility of losing these changes if the developer forgets to share the change with other teammates.
• Due to non-existence of repository systems, some code would be lost if any computer gets damaged.
• Due to non-existence of repository systems, developers would always face a problem where some projects are missing or not synced with the production versions (especially for old clients), so they found themselves getting the deployed application from the site and decompiling it to get the latest version of a project (though this is not always feasible).

5. Late deliveries:

• Due to the complexity of the code, maintenance would be very hard and any simple task would take a lot of time more than normal , so this leads to a late project deliveries.

Summary

Continuing our series about applying process in software development, in this article we’re going to elaborate how applying process would impact positively the software and the team structure. If you don’t have an idea of what i’m talking about, please refer to my first article SDLC in practice: practical definition.

Next Steps

If you're interested in learning more about the basics of Java, coding, and software development, check out our Coding Essentials Guidebook for Developers, where we cover the essential languages, concepts, and tools that you'll need to become a professional developer.

Thanks and happy coding! We hope you enjoyed this article. If you have any questions or comments, feel free to reach out to jacob@initialcommit.io.