Software Development Roles and Organizational Process

This is a Guest Post by Jim Smith from engineerjames.com for Green & White. Jim is a software developer from Philadelphia, Pennsylvania and has been a C / C++ developer on Linux and Windows since 1997.

In this post Jim analyzes and describes the importance of implementing a software development process and methodology in organizations.

Energy is nebulous until it is directed by methods and processes. This is especially true when the energy is generated by the effort of individuals of a large corporation trying to accomplish an engineering task. Just as the circuits in analog appliances direct the flow of energy, methods and processes direct the flow of energy used to perform work in companies, large and small. The effectiveness of the methods developed for accomplishing tasks and the level of commitment employees have to the systems of an organization are key indicators of a company’s performance. No organization should attempt to produce a product or service without reliable systems directing their daily operations. Many organizations do attempt such feats and this is the cause of the quality problems in many companies today. Time constraints and the other demands are not acceptable excuses to sacrifice discipline.

Systems, processes, and methods always have a tremendous impact on the success or failure of I.T projects. Project success is not inevitable. Individuals performing software development roles in I.T. departments must be aware of the possibility of one or more steps in some adopted method being inappropriate for a particular application. This is where we find room for improvement and for new approaches to solving problems that have been learnt through experience.

Systems are broken down into manageable parts to give way to an entrepreneurial approach to development. This means that the process is broken down into tasks performed by team members.

Each team member takes responsibility for his or her work and develops their own strategic plan for implementing their work.

Those carrying out the SD roles inside organizations must have a commitment to the process that orchestrates how things are done on a daily basis, but at the same time they must not be so hardened by the process that inefficient procedures that hinder performance go unnoticed. There are occasions when some method that is part of a process is not applicable for some reason. There must be room for improvements regulated by guidelines that do not hinder progress.

If some analysis method is not able to be performed due to some constraint, the absence of this method should be recognized and excluded as soon as the constraint is seen in the initial requirements, for instance time constraints could make something impossible to perform within the time allocated for a task.

When effective processes are in place implementing solutions become trivial compared to what was initially presented to the engineering and I.T. teams. Request presented to the I.T department usually cannot be converted directly into engineering task. Management teams that are sources of information for things pertaining to new products or features don’t present requirements from a standpoint that engineers can use for functional design. The purpose of standard processes is to normalize these requirements, and once these happen the solutions are then much easier to find.

An established I.T process digests the information presented to the department and distributes it to parts of the organization responsible for the work.

The work performed through this distributed knowledge is the same work that implements the solution to the problem. Those holding the software development roles are the organs of the system that performs the work. They must have a clear understanding of their responsibilities and should be committed to the process.

The process can be measured by how efficiently it solves a problem. Requirements coming into the I.T department creates a chaotic reaction if the processes used by the engineers are not powerful enough to regulate and direct how the information is moved throughout department. If the procedures are weak, we would observe redundant information, overlapping requirements and changes to requirements that results in complex dependencies.

At the core of the data received by the I.T department is the requirement. The normalization of the data sent to the I.T department must be done effectively enough to avoid the weaknesses mentioned above and the result used to create more granular functional designs. In I.T departments these requirement documents contain the information needed to find application types such as C++ modules, classes and abstractions.

Sometimes there are no established I.T processes in place. I have worked for more than one organization that believed that a formal development process was not necessary because their projects were either not large or complex enough, or that the engineers were so talented that they could work without processes that regulated development work.

I was criticized for attempting to implement formal engineering strategies even for my own work. The result of not having a system in place was chaos in every case, bad quality and performance, but still it appeared that in many firms this chaos was accepted as the normal state of the I.T department.

Moreover, in smaller companies, upper management teams (mainly those managers involved in process control and development) lost control and authority of the service and products offered by the company and the engineers where pretty much in control of everything.

Systems that move information around within organization and how they are designed is a firm indicator of upper management’s desire to maintain control of organizational operations.

When knowledge is not distributed properly because of poor process or lack of commitment, upper management will lose control because they will not be able to track performance, understand system design or coordinate activities within the company.

For example, each Design Document contains the knowledge needed by management to set effective milestones and targets that are concrete enough to measure performance. By not requiring that the engineering department work within a system that produces and distributes their development data throughout the company, the company essentially turns all control of engineering over to the developers.

This is not good, because every department should be open to checks and cross checks by outside controllers. The result of such inefficiencies is that upper management cannot make good decisions about the design, implementation or future direction of the system. In most cases the organizational process is relied on to produce the data that is the locust of the decision making process.

In every case the time you spend dealing with problems due to a bad processes will be more costly than the time taken to develop formal procedures and follow them correctly. To some extent engineers must change who they are in order to accept new ways of doing things.

To end this I would like to say that, systems take on a personality that resembles the implementer. Standard procedures keep the companies personality or character on the systems implementation not the personality of individual developers.