Minimalism and signs
In the workshop at SPA 2005 on beauty[1] I was thinking about clarity and minimalism. I value doing something one way. That is, if you are going to introduce a construct, you do it in a consistent manner. I think this is important because someone working on the code is building a model of the system in their mind and consistency helps. If, when they see a certain pattern of implementation, they can always map it to the same intent, they have less to learn than if the same thing is done in different ways in different places in the code.
What is happening (perhaps) is that the code authors are building a shared (and private) language of signs. Since signifiers are somewhat arbitrary and cultural specific it is certain that a team of people will come to the project with different sign systems. To ensure clarity of communication and a shallow learning curve, the team need first to use signs that the team have a shared common understanding of. Secondly, the team have to evolve their own sign system that all buy into. Finally, the authors need to make sure the same signifier is used to represent the same concept throughout the code. When authors don't do this, teams always complain of inconsistency. Worse still, team members may attribute their own concept to the signifier and make incorrect assumptions. This line of thought leads me to think that minimalism and clarity are concerned with creating a system with a minimum set of signs (at some level of abstraction) where one concept is not represented in the code by multiple signifiers. Furthermore, to ensure clarity, the signs should be understood by the team and by the community from which maintainers will be drawn. This in turn infers that the software becomes targetted at a specific design or implementation school of thought.
In conclusion, all things being equal, it makes sense for a team to use a sign they all understand. It maybe that the technology underlying the signified concept is the same, but if the team do not have an understanding of the signifier, confusion and defects await.
What is happening (perhaps) is that the code authors are building a shared (and private) language of signs. Since signifiers are somewhat arbitrary and cultural specific it is certain that a team of people will come to the project with different sign systems. To ensure clarity of communication and a shallow learning curve, the team need first to use signs that the team have a shared common understanding of. Secondly, the team have to evolve their own sign system that all buy into. Finally, the authors need to make sure the same signifier is used to represent the same concept throughout the code. When authors don't do this, teams always complain of inconsistency. Worse still, team members may attribute their own concept to the signifier and make incorrect assumptions. This line of thought leads me to think that minimalism and clarity are concerned with creating a system with a minimum set of signs (at some level of abstraction) where one concept is not represented in the code by multiple signifiers. Furthermore, to ensure clarity, the signs should be understood by the team and by the community from which maintainers will be drawn. This in turn infers that the software becomes targetted at a specific design or implementation school of thought.
In conclusion, all things being equal, it makes sense for a team to use a sign they all understand. It maybe that the technology underlying the signified concept is the same, but if the team do not have an understanding of the signifier, confusion and defects await.
posted by Andy S at 5:43 PM
<< Home