JH Rainwater "How to graze cats": on the other side of development

We continue to share extracts from the manual for those who are preparing to head the development team. In the previous part, we talked about everything alien, which lies in wait for the technical leader in the new position, now we return to things familiar and familiar – programming itself. Here, yesterday’s developer can feel in his element, but he does not have to relax – the area of ​​responsibility is growing and shifting. Under cat, we present a brief overview of all the new responsibilities and adaptation tips that Rainwater cites in his book.

The fundamental difference lies in two nuances. Firstly, the lead comes into the process much earlier and does not turn off from it until the victorious end. Secondly, while the developer is focused on the narrow task that is set for him, his boss reviews the product in its entirety, while not forgetting to go into details when the situation requires it. Let's go together with the author in order and try to outline the role of the team leader at each stage of the application creation.

Definition of requirements and specifications

A good techlide begins to work with the product even when it is in the perinatal state – that is, in the form of a general idea, request or list of functions. However, here you need to immediately clarify: Rainwater strongly believes that the developer should not be engaged in the work of a marketer or product manager — or rather, he should avoid this scenario with all his might. Not that it was impossible or reprehensible for the “techie” to understand market realities and commercial requirements, but combining these two roles is very difficult. Among other things, there is a greater risk that the internal developer will win and the characteristics of the product will be tailored to the interests of the team of programmers, rather than the end user. It is much easier and safer to work when the general vision of the product in terms of its functionality is already prepared and tested for viability by knowledgeable people.

For the mixing of two roles, developers who in our classification are often referred to as a cowboy breed often advocate – they yearn for "garage" times when tiny teams made the entire product from and to and there was no need for external interaction. The author is in a hurry to dispel all illusions on this score: in modern conditions, the interaction between technical and non-technical groups should occur regularly, throughout the life cycle of the application. The first meetings are held for the joint preparation of specifications. The development manager (or one of the leading developers) gets acquainted with the product description, excludes everything that seems to him unjustified or unrealistic from a technical point of view and picks up the final plan in order to translate it into the language of technologies. Then groups meet from time to time to “check the clock” and make sure that the implementation does not deviate too much from the original plan.

The recommended frequency of such meetings is about once a week, although, of course, you need to make adjustments to the general pace of development and the features of the organization of processes for a particular company.

Regular meetings will also be needed for another reason – attempts to deviate from the original course are likely to come not only from the development side. Most of the applications, in order to remain competitive, are constantly overgrown with additional tools and capabilities. Therefore, the process of reviewing, evaluating and dropping out ideas can be repeated ad infinitum, only on a smaller scale than for primary specifications. It is extremely important for Tehlid to keep abreast of the plans for product development – this not only gives him room for maneuver from an organizational point of view (allocation of responsibilities, determination of terms), but also allows you to calculate in advance the consequences for the system as a whole, its harmony and sustainability.

Before you agree to take a new function to work, you should ask yourself a number of questions:

  • What impact will the proposed change have on the system architecture in the short and long term?
  • How will the proposed change affect the network infrastructure in which it will take place?
  • How will the proposed change affect the user's ability to interact effectively and productively with this product?
  • What impact will the proposed change have on the actions of employees who have to work closely with him – to implement, to accompany?

Such reflections will help identify pitfalls and set general directions for dialogue with other groups.

Design

When the requirements are approved and blessed by all participants in the process, the time comes for what Rainwater calls coordination of architectural and design decisions. In other words, the technical guide needs to describe the system that will perform the functions specified at the stage of specifications, and think over the components responsible for specific procedures. It is critical to act in this order:

Architecture first, then components.

The author emphasizes this many times, because many developers who are not familiar with the art of product design fall into this trap. It seems logical to take a list of requirements, prescribe the necessary components for each and consider the product as a simple combination of them. But in reality, this mechanistic approach gives rise to rigid, randomly organized monsters that suck all the juices from the developers involved in supporting the project. To avoid this, you need to go the other way, from the whole to the particular. You already have a common functional vision of the product with a development perspective – you need to “mirror” it in your general technical vision with a development perspective, that is, architecture.

Building architecture

If you resort to a hackneyed metaphor, architecture is the skeleton of the product, on which the flesh from private decisions on the implementation of procedures is then built up. We revive this metaphor a little, adding a clarification: the skeleton must be sharpened in order to grow new limbs. The two main requirements for architecture are a clear logical organization of components and flexibility that will add new ones as the project grows.

Perhaps this stage in the development can perhaps be called the most responsible – experts say that it is neglect of architecture that most often leads to the collapse of projects. Among the common causes of failure, they name:

  • Lack of thought, sloppy organization (or its complete absence).
  • Excessive rigidity and straightforwardness of the system, preventing its expansion in accordance with commercial needs.
  • Excessive interconnectivity of components, lack of flexibility in configuration.
  • Excessive complexity at the upper levels, making it difficult to modify the basic components.

Accordingly, the task of building architecture should be approached with all seriousness, not sparing resources. Remember that you are laying the foundation with which you have to work until the very end – it must withstand all the changes that await the project in the future. This process is largely creative and visionary, but standard methods of structuring are useful for balancing the system. For example, draw a block diagram with a full set of connections or even implement a simple layout (a set of low-level components with stubs and return values) to make sure that the architecture works in a vertical projection. The latter is very desirable to do before starting the development of real, full-fledged components – eliminating bugs with "toy" elements is much easier and more painless.

By the end of the work at this stage, you should be ready to answer the following questions:

  • How will the user interact with the system?
  • What components need to be assembled in order to ensure the functioning of the system?
  • What will be the mechanism for the interaction of components that ensures the functioning of the system?
  • What technologies are best suited to create this application?
  • How is it supposed to deliver the system to the client?

Component planning

When the general framework is developed, it is time to delve in particular and implant the currently relevant components into the organic structure. The main difficulty here is to withstand the necessary measure of connectedness. On the one hand, components should not be considered as strictly isolated containers for specific sets of operations — rather, as a system of organs, each of which communicates with the others, but performs its functions. At the same time, strong interdependence between the regions should be avoided, as a result of which the modification of one component will lead to a whole chain of changes, or even malfunctions, throughout the system.

The technology stack was outlined at the last stage, now you have to comprehend it in detail. In the choice of language, libraries, and as further it makes sense to be guided not only by professional, but also strictly pragmatic motives. Say, will you have enough competent personnel to support systems built on the basis of advanced, rare or complex technologies? And vice versa, if you give preference to older technologies, how promising is it – will they remain working throughout the entire life cycle, will compatibility problems begin to arise? All issues related to hardware solutions, creation, configuration and maintenance of infrastructure should be considered with the same care.

Development and quality control

So, the planning is finally completed and the project goes to work – the actual development of the application begins. The role of the technical leader in this process consists mainly in monitoring, so that everything goes in accordance with the terms and standards; he is directly involved in code creation, as a rule, only in force majeure situations. For the most part, the head performs the functions of the code police, that is, conducts regular critical reviews of the code to make sure that they do not contradict the architectural framework and the basic principles of programming.

During inspections, the technical leader may encounter different types of errors. Rainwater focuses the reader on two varieties:

  • Violation of standards. This includes styling, naming, commenting – in general, everything that helps a third-party understand what is happening in the code, as well as carelessness in the spirit of several exit points or hated GoTo statements. It is necessary to ensure that all participants in the development process speak the same language – this makes the code transparent and allows you to quickly unravel erroneous moves. The names of parameters and variables should clearly indicate their content, comments should help to trace the code of a developer’s thoughts, justify his decisions. By the way, if someone from the team stubbornly refuses to comment on the code, it is worth considering why. Often this is just laziness or a peculiarity of thinking, but in some cases it can be a symptom that the employee himself does not really understand what he is doing – confused or just copying pieces of someone else’s code for good reason. It is also necessary to carefully monitor those who regularly neglect error handling: inability to identify sources of bugs is a serious flaw for the developer.
  • Weak connectivity and strong interdependence – two areas of violations that can be considered together, since the presence of one implies the presence of the other. Here everything actually rests on the degree of branching and its type. With a high degree of branching in terms of output, the functioning of the procedure involves access to many other procedures, which, of course, is undesirable. Branching at the entrance, on the contrary, has a positive effect, since it indicates strict encapsulation. If you have doubts when analyzing the code for these parameters, it would be nice to draw up a block diagram with a marked hierarchy of objects. It immediately reveals everything you need to know: is it possible to trace the pedigree of the object, is there logic in the arrangement of arrows, or does everything look messy.

If the code police detected violations in these and other areas, the arrest procedure looks like this: the code is sent back to the developer with the necessary comments, work on the corresponding component is suspended until the defects are fixed. It is highly desirable that the developer handle this himself, albeit with tips – if you do everything for him, the mentoring component of the code inspection is lost.

Do not postpone revision until better times. Firstly, it can strongly come back in the future and require much more resources to fix all the snowball troubles. Secondly, the theory of broken windows also works in programming – untidy, confused code creates even more untidy, confused code, simply because it seems valid.

Finally, speaking of quality control, one cannot but touch upon the problem of the notorious human factor. Rainwater recommends that the manager take a middle position. Some degree of resistance to interference with the code is natural and benign. A complete willingness to follow someone else’s instructions and accept someone else’s opinion should even alert you – often this indicates that the developer, in fact, does not care what he releases. But on the other hand, the inability to perceive sound criticism hinders both professional growth and teamwork. Accordingly, the technlide will have to grow thicker skin and not be afraid to insist on her own, without taking a negative reaction to her heart.

Testing

Here, it is important for the leader to keep two basic rules in mind: testing should be conducted and organizing its conduct is your responsibility. If the company has a testing department that is naturally involved in the processes, then no problems will arise with this. If not, you will have to allocate a resource from your own reserves for this matter.
In the second scenario, according to the author, there are certain advantages: testing is a useful skill for the developer. It is especially useful to attract newcomers to these tasks, so that they quickly acquire qualifications. At first, you can take up testing tasks for up to half of their working time.

Otherwise, to ensure a good quality of inspection, it is necessary to ensure that the product does not cook all the time in the same group – ideally, it should be tested “on the side”. If a company has several development teams, it may make sense to agree with other leaders to create a mixed group.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *