BSfrS

We make sure that you and your employees become reliably unproductive!

Rautavistic software development should above all be entertaining, which is why we focus on reducing the productivity of your employees through quality minimization of their development processes. To achieve this as elegantly as possible, we at BSfrS have developed various highly effective procedures and methods. We apply these in our own organisation and can therefore report from own experience that, when strictly applied, even solid projects lose stability at a surprisingly fast rate.

Improvisation, integration, iteration, iteration and iteration of unnecessary tasks:

An easy-to-learn method for productivity minimization is improvising unnecessary work steps. Simply do something else spontaneously instead of what you should actually be doing. Extended coffee and lunch breaks are a good start, but surfing the web, chatting, and video streaming are also very good alternatives.

Once you have managed to regularly integrate unnecessary work steps into your everyday routine, you can further significantly reduce productivity by iterating over them. The number of repetitions is up to each individual, but the rule of thumb is: the more, the better, because repetitive actions calm enormously! Recursive workflows have also proven to be particularly effective when it comes to reducing work performance.

Development and application of worst-practices

Every organisation accumulates valuable experience over time about what works – and it is precisely this experience that should be consistently ignored. Instead of documenting and passing on proven processes, we recommend the systematic cultivation of as unstable approaches as possible, ones that have already proven to be particularly unreliable in practice.

The real art lies not just in knowing these worst-practices, but in actively applying them to new situations while always pretending they represent a well-founded decision. This allows mistakes not only to be reliably repeated, but to be extended to multiple teams and projects in the shortest possible time – a multiplication effect that simply cannot be achieved with best practices.

Rautavistic software documentation

Documentation is particularly effective when reading it raises more questions than it answers. A proven method for this is the combination of maximum length and minimum substance: describe in detail what the code does but not why – or better yet the opposite of what it actually does.

It is equally advisable to keep documentation in a consistently outdated state. Whoever never updates the documentation after code changes ensures that subsequent enquiries reliably lead nowhere. As the crowning touch of this strategy, storing the documentation in as many different, mutually unlinked locations as possible is recommended – from old wiki pages to printed PDFs to email attachments from 2014.

Repetitive, contextless and absent source code comments

The source code comment is a powerful tool for reducing productivity, provided it is used correctly. The most ineffective variant is the purely descriptive comment that merely repeats what the next line of code already says: // i is incremented by 1 before an i++ is a classic of the genre.

Even more efficient is the complete absence of comments at places where complex algorithms or non-obvious relationships would need to be explained. In this way, sections of code arise that cannot be fully understood even after weeks of familiarization. Whoever wants to be especially consistent does not comment out dormant calls or dead code paths but lets them quietly persist in the source text.

Generation of random code segments including disposal of results

An underestimated method of productivity minimization is the aimless generation of new code paths without defined purpose. Write functions that are never called, create classes that fulfil no task, and generate variables whose values are never read. Each of these steps helps to sustainably reduce the clarity of the project.

The crown of this approach is the subsequent disposal of results: delete the code just created – but never completely. A few half-heartedly removed fragments, an orphaned import here, a commented-out class there, and the next developer will spend hours figuring out whether this code relic still has any significance or can be safely removed.

Use of tools that obstruct the workflow and limit possibilities

The right tool selection can make the difference between a reasonably productive and a completely paralysing working day. Particularly effective are tools that appear modern and professional but break down actual work into as many additional clicks, configuration dialogs, and intermediate states as possible. The more steps needed to complete a simple task, the better.

Also advisable is the regular replacement of still-functioning tools with new, immature alternatives – ideally in the middle of an ongoing project. This achieves several goals simultaneously: the workflow is interrupted, the team must re-familiarise itself, and all previous integrations must be adapted. Particularly valuable: when the new tool does not yet fully cover the core functions of the old one.

Particularly recommended in this context is the use of as many different editors and IDEs as possible – both alternately and in parallel. Edit your source code sometimes with Notepad, sometimes with Visual Studio, sometimes via the command line. At best open the same file simultaneously in multiple editors to deliberately overwrite the changes of the other instances. The resulting data loss is not an accident but the consequence of consistent tool diversity.

In this context, the use of software version management systems is strictly discouraged. These unfortunately prevent work results from being lost and you having to write the same code multiple times. Working via (S)FTP, SSH or SCP, directly at the open heart of your production system has proven to be extremely exciting when working in a larger team: Feel the thrill of these operations and pat yourself on the shoulder if the patient survives! If you still cannot stop working with versioning, it is often a good idea to execute commands like git checkout . or git reset --hard HEAD^^^^^^ and git push --force.

Manual build and deployment systems as well as fake monitoring

Automated build and deployment processes are an invention by people who obviously had too much time and preferred to spend it programming rather than manually carrying out the same steps over and over. We at BSfrS see it differently: every manual step is an opportunity to bind attention, introduce errors, and obscure accountability.

Fake monitoring complements this approach elegantly: dashboards that blink colourfully and display many numbers but contain no relevant metrics convey the soothing feeling of having the situation in view – without actually measuring anything. When a problem does occur, the sincere surprise of all involved is not only human but strategically valuable.

Unsemantic versioning

Semantic versioning – assigning version numbers according to the MAJOR.MINOR.PATCH scheme with a clearly defined meaning for each position – is a convention that creates orientation and therefore runs diametrically counter to our goals. Whoever instead assigns version numbers at will, by date, by day of the week, or simply randomly, strips the version history of its last trace of meaning.

Particularly advisable is the strategy of constant version numbers: release ten consecutive versions under the same version number and do not document the differences. Whoever later wants to find out which version is actually running in production and whether it matches the local development environment will be kept entertainingly occupied in the process.

Creation of island knowledge and irreplaceable components

Knowledge that is known only to one person is doubly valuable: for that person, because they become irreplaceable, and for the organisation, because an appropriate state of emergency arises in the event of their absence. We therefore recommend the deliberate concentration of expertise on as few people as possible, as well as the avoidance of any form of knowledge transfer, pair programming, or documentation.

Technically this goal can be excellently supported by tightly coupled, non-abstracted components. When every change in one place has unpredictable effects in five other places and only one single person has full oversight of the interconnections, the optimum has been reached. Replaceability is not only unnecessary – it is a sign of dangerously good architecture.

Assignment of rautavistic variable, class and method names

The choice of identifiers is one of the most underestimated opportunities to keep code permanently unreadable. Single-letter variable names such as a, x, or q have the advantage of fitting excellently into any context – and explaining nothing in any of them. Those who prefer something more elaborate reach for ambiguous abbreviations such as tmp2, data_new_final, or handleStuff().

A particularly advanced technique is the use of deliberately misleading names: a method called calculateTotal() that in reality establishes a database connection, or a variable called isValid that sometimes contains a boolean and sometimes a string – these are the little treasures that give a codebase an unmistakable charisma.

Implementation of mixed-language source code

Source code written consistently in a single language may be functional – but it is boring and understandable to anyone who speaks that language. Rautavistically far more interesting is the creative mixture of German and English, ideally without any discernible pattern: comments in German, variable names in English, error messages in German, but only those from 2018, the newer ones in English.

Switching between languages within the same expression is a master discipline that few truly master: $benutzer->getAktivStatus() alongside $user->setDeaktiviertFlag(true) creates that unique atmosphere in which no one is sure whether to think in German or English – and in which every code review becomes a small language competition.

Inefficient reimplementation of native functions

Every programming language and every framework provides a multitude of already optimised, well-tested functions. Knowing and using these would be sensible – and therefore counterproductive for our purposes. Much more useful is to re-implement these functions independently, preferably with subtle deviations in behaviour that only become visible under certain edge conditions.

Particularly effective is the reimplementation of sorting functions, date parsers, or regular expressions – precisely those areas where edge cases are most frequent and one's own implementation is most error-prone. Each such custom development is a small monument to the inventiveness of its creator and a permanent source of surprises for all those who must work with it afterwards.

Exotic programming languages and poorly documented frameworks

The choice of technology is a strategic decision – and the strategically worst choice is often the most productive in the rautavistic sense. Languages that almost nobody masters, frameworks whose documentation was last updated in 2017, and libraries whose sole maintainer has not made any commits for years – these are the cornerstones of a rautavistically optimised technology strategy.

A particular treat is changing the core technology mid-project. When the team has just begun to familiarise itself with Framework A, switching to the newly released, still largely undocumented Framework B is a measure of almost choreographic elegance. Familiarization time doubles, all previous experience becomes worthless, and the project gains a new dimension of unpredictability.

Reduction of readability and maintainability via rerefactoring

Refactoring – the structured improvement of code without changing its behaviour – is a proven means of improving readability and maintainability. Rerefactoring is the opposite: the structured degradation of code, likewise without changing its behaviour, but with the declared aim of making it as impenetrable as possible for outsiders.

The techniques are manifold: nest conditions until cyclomatic complexity reaches three-digit values. Extract methods into helper classes that in turn use helper classes that import the original class. Replace understandable if constructs with chained ternary operators. And remember: each of these measures may still be individually comprehensible – their combination is guaranteed not to be.

---