2015_10 "the-best-that-I-know-of" Version of Software Development Methodology

No Comments

The main purpose of this article is to simplify job interviews, save time from explaining the same thing all over again in different wordings to different parties. This article is not about software technology, but about the social principles of teamwork at software development projects. The core of the answer is that for naturally curious and observant people only fun combined with the minimization of factors that disturb the fun is the thing that gets them to do X in stead of committing suicide. The rest of the contemplation is about how to make the fun part possible, while allowing multiple bright people to simultaneously enjoy X by cooperation among themselves, without stepping on each-others' tows, and how to make that process to be valuable to third parties so that they are voluntarily willing to pay for the activity of the bright people.

Of course, different social organization principles are required for different participants. 4 year old children require one way of getting them to do something "useful", apes in the jungle need different "leadership" and "corporate culture", people with lack of self motivation will probably be more productive in pair programming, an "average joe", who finds drinking in nightclubs the way to enjoy life, might find "scrum" the best way to work, etc. Organizing the work of creative scientists, who like to be thorough and think things trough, by requiring them to adhere to the "scrum", is a very effective way to get resignations. Software can also be developed in multiple, different, ways: slam something quickly together and then hope that the client will never use data that was not covered by the test data set, or, think things trough, design software, take time to think things trough and apply the thorough thinking recursively to all sub-tasks. Generally I(Martin Vahi) am one of those people, who wants to take time for thinking. That explains part of my subjective, taste based, choices for the design of the software development methodology that I describe in this article.




The Methodology

To keep people from stepping on each other's tows, their work is sandboxed to sub-modules/code-regions where only the public API of the module is the way to communicate with the modules. The sandboxes have also other limits, like maximum memory usage bursts, maximum continuous memory usage, bandwidth usage, etc. Within their sandboxes the developers can do absolutely whatever they want, use whatever programming language that they want, use whatever coding style that they want, with a limit that the coding style that they use must be supported by an automated code formatter, which they themseves choose. If the formatter can be used as some web service, then there's no limit on the operating system that the formatter requires, as long as the operating system license and hardware is affordable. Within the sandbox all esoteric and exotic programming languages are allowed.

The architect, who lays out the sandboxes, is responsible for planning the set of sandboxes so that the sandboxes cover the features that make the software useful for the party that pays for the development. The architect is responsible for taking to account the motivations of different developers. The architect is responsible for understanding the areas of interests of different developers and is expected to make an effort to solve a BackPack problem by allocating the sandboxes so that the interests are covered to somewhat maximized amount. Although the architect has the final say about the allocations, the solution is optimized by holding a group meeting, where the architect offers an initial, seed solution that is expected to be changed radically during the meeting. The architect must keep himself in shape by working in one of the sandboxes himself, by writing actual, production code. The architect picks his sandbox only after all the rest of the members have chosen theirs, that is to say, the architect is expected to do the jobs that others do not want to do and the architect can suggest sandbox-developer relations, but specific sandboxes should be allocated to specific developers only as a measure of last resort.

Just like it was with the Manhattan project, it is OK to have duplicating sandboxes. Not only can duplication mitigate a situation, where the architect does not believe in the capabilities of some developer, but it can also be the case that the same functionality can have multiple, different, parameters, like code before Just-in-Time Compilation and code after Just-in-Time Compilation or pure Ruby implementation versus faster, slower-to-create, more optimized, C++ based Ruby gem (with C interface). In addition to optimizing the probabilistic resource allocation, interests coverage, probabilistic schedules of a single project, the architect is responsible for suggesting a plan, how to minimize the development work across projects, probably leading to a situation, where in the name of the "global work minimization" the work amount of some projects can be greater than if the development work of the projects were optimized "locally". For example, the development of properly designed interfaces can be seen as an "extra" work that might be skipped, if the components of the project were not made re-usable for other projects and the components are likely to have some "extra" requirements imposed upon them by the other projects. Despite the fact that the architect has the final say, the interests of other developers can only be covered by getting to know the interests and by negotiating with them. The interests of developers also determine, what kind of components can be developed. Component options determine the maximum effectiveness of the inter-project, "global", work optimization, which in turn determines the overall cost of development across multiple projects.




Walking in the Neighbor's Sandbox

Apart from the limits set by the architect, the owner of the sandbox has the final say about everything in his/her sandbox, no matter what. Each sandbox has only a single owner. Sometimes people would like to ask for comments, want to have the freedom to do pair-programming or they just get hit by a train or need someone to replace them during hospital days. In the case of the various C++ memory related flaws there can be violations of sandbox limits that need to be eliminated regardless of the availability of the sandbox owner. To keep people happy, people must have the freedom to do their coding in whatever IDE and use the code formatting style of their choice. The formatter availability requirement comes from the idea that if a sandbox is recursively re-formatted prior to every commit, the diff-tool allows to track the changes of different authors. In an era, where manual security audits are not an option, every sandbox owner self decides, when, to what extent, if at all, which code analysis tool he/she uses. Company-wide code style requirements are too repressive and too limiting to smart and creative people, who thrive for ever-improving craftsmanship and want to experiment for finding improved ways of doing their job.




Mentoring and Research

Just like by knowing all physical properties of bricks it is not possible to derive knowledge about all possible buildings that can be built from them, it is not possible to know, how insects "work" by knowing quantum physics and the Mendeleev table. The same with software: good knowledge of the components does not give adequate amount of information about their composite. As software development is an activity, where components are created and combined, it is a walk in the unknown, generally known as research. (Leaving the theory of computation and a like to aside, it would be an utterly stupid to pay the gigantic amounts of money for work that could be replaced by copying files from one folder to another.)

Learning and research is one and the same, because in order to construct a novel experiment, the experimenter benefits from knowing, what others have tried before and in order to understand, what others have tried before, some, not all, experiments of others need to be repeated by constructing them in one's own style, rephrasing the ideas in one's own words. Therefore mentoring can only be in the form of really attractive or intriguing suggestions that the learning party self prefers to try out rather than being blackmailed to execute. Learning is a creative activity, not mundane, dumb, repetition. Learners have to find their own wording to the ideas that the "giants before them" have to offer. What regards to evaluation of solutions, then there are no good or bad solutions, there are only solutions that contradict with the learner's stated goals and even that is subject to interpretation. For example, a plane is not necessarily faster than a ship, if an average (number-of-passengers/hour)/km is observed, but it is possible to argue that latency of a plane based logistics system is smaller than that of a ship based logistics system. Best practices exist only in tyrannies, nursery schools, armies of slaves. A really good mentor/teacher is a mixture of a psychotherapist and a performer, who uses the skills of psychology and the skills of a performer to choose the place, time, mode, style of execution and uses the skills of the specialist for coming up with the intriguing comments, stories, tales, observations, suggestions, references, questions, illustrations, sample solutions, etc.

What regards to meetings, then they should never have "too many" participants, because otherwise everyone's topics can not be covered. The number of participants should be small enough to allow the exchange of information take place in stead of making the meeting an "opera", where a select few talk, "sing", and a whole mass of people quietly listens. It's useful, if team members briefly describe their problems to each other in about once a week, because multiple people might have the same problem and they might have different partial solutions to the problem or someone might have even a properly working solution that others like.




Product Testing

Testing is each sandbox owner's personal affair. Sandbox owners can even skip testing, if they choose to. For example, some of them might find that formal verification is enough. Just as is the previously described case with the brick and the insects, integration tests can not be replaced by any level of analysis of the individual components. The integration tests are for the architect to organize. Maintenance of the integration test system is a separate, internal, software project with the same style of setup as the external, sellable, projects are. Integration test systems can have integration tests, can have integration test systems, can have integration tests, can have integration test systems, ..., is is ultimately un-tested and based on gut feeling, hope, faith, definitions from dreams.




Project Documentation
The general documentation is maintained by the architect, but it is up to the sandbox owners to decide, how much they document their work. Documentation of the interfaces of the sandboxes, including the build instructions, must be provided by the sandbox owners. That may include documentation that targets end users. Of course, it is all subject to negotiations and the "average" fun of the work is a requirement that can never be overridden.

Comments are closed for this post