Recently I witnessed the umpteenth dysfunctional behaviour between developers and systems engineer (nothing new below the sun). The subject of the debate was the backup of several customers' databases used by a software application built by developers, and each group was repeatedly passing the buck to the other one; systems engineers said "you built the application, you perform and collect backups", developers said "you are in charge for all backups, these should not be treated differently". Obviously the hidden agenda was trying to avoid a task nobody likes. It was all worsened by the fact that Xmas holidays and consequent vacancies are approaching, and several people will be home playing the couch potato.And who was wrong? And who was right? It didn't matter in the thick of the fight...
I think that the right approach is "hey we're in all this together, let's talk and get a solution out of it", but sometimes a long history of untrust and urban guerrilla warfare can be hard to overcome.
Anyway, as a game, let's see if some software development principles and patterns can also apply to people :-)
- Rigor and formality: formality is a plus (sometimes it can be a burden), but rigor must always be present.
- Separation of concerns: complex systems are difficult to analyze, and it is very difficult to manage the process that leads to deliver. To overcome this point we try to separately manage unrelated issues. This is why we have developers AND systems engineers...
- Modularity: it is a specialization of the former
- Abstraction: complexity worsen the capability to build models that are effective for resolving the problem, thus we abstract from details that are not relevant to the goal. Is it important to know where databases to be backupped come from?
- Anticipation of change: YAGNI :-)
- Generality and Incrementality: following the Abstraction principle, we abstract and do not consider them now
No comments:
Post a Comment