Artful Ownership

In a relationship-driven business world, job security and software maintainability are directly and inversely related. Gothically this happens both through a carrot and stick approach from the developer toward the management team and also from a developer to his own future self.

Promoting ownership stimulates the desire to create maintainable code. Much like the difference between renting an apartment and owning a house, the developer who recognizes that he owns (and is responsible for) the code has a vested interest in being able to go back years from now to understand how it works.

Management teams that swap out developers like machine cogs create a separation between a developer and his code: in essence the developer becomes a "renter" and he will deliberately obfuscate his work. One because he has no incentive to spend the extra effort to make it maintainable, and two because he will strive for job security by obscurity: he punishes the management for his insecurity by complicating their desire for robotic interchangeable developers.

In some cases though software may be a one-shot throwaway: if management expects the march of technology to obsolete a software platform rapidly then it might not particularly care whether it is maintainable. Hence if a developer would rather own than rent, he better darn well be sure that he works on creating a substantial and mission-critical system that his employer will still be relying on, with the same platform, six or seven years from now.

Yet... ownership is a chimera. It is an intentional feeling rather than an actual reality. Legally the developer does not own the fruits of his work. How can management promote the feeling of ownership even though the legal reality is otherwise? If it fails to do so it can never expect developers to create lasting platforms.