About the NOOB definition– Part 2: Globalization.
April 26th, 2008
Prior the Internet days (some people talk about prior television), we had different villages, local ones, with no communication. Now, we live in a global village. We need to communicate and share knowledge, even in different languages and cultures. Furthermore, we learned it is not just us and the "my limited world", but any thing we do affects the globality.
Now, when working on a real world problem, working to find a solution of course, we need to communicate and all or our work is to complement the one from others. There is no one single person that fights all the villains and the rest of the team observes and cheers.
Solving a problem with a software intensive system, involves working with all parts of the system: Hardware, Software, people and processes. No one lives alone with its computer, everybody interacts with all the other components of the system, and the developers are part of that system too!.
Making sense of that, the strategy of working only in my local line forgetting there is something beyond that, goes back to the local world and denies globality. Does it mean you need to work all at the same time? No. It means you work in your local line knowing there is something bigger of which that line is an important part.
What does this matter in Steve Yegge’s post about NOOBs? Well, going extreme, the post indicates there is much waste, fat we need to remove to be healthy. The comments, even the modeling and describing language structures are needless for the seasoned, non-noob programmer. I agree, as long as the programmer is working in a system that has only two components: the programmer and his lines of code.
Unfortunately, that is not the reality. A system not only requires the work of many other components, some non-software and some non-programmers, but also requires all those components to communicate at design and execution time. Robert Martin once said that one of the software functions is actually communicate with people, readers that may have not participated in the development. Does that mean the comments should stay? Not exactly, but that the code itself should be readable, understandable.
One way of doing that, for the development group, is using sentences that make sense and do the function (you can scramble the sentences and do the same thing but being not readable).
Globalization in the System means all components will need to communicate and work with other components. Creating the product with those characteristics, because they are needed, is not being NOOB, but being aware of the fact the software is not an island.
William Martinez.
Trackback address for this post
1 comment
It has long been realised that the ideal solution to software complexity is to have teams that acts as one. A single brain with many hands, capable of understanding both the problem domain, and the solution space, and capable of translating from one to the other in a language that both the computer and human beings can understand.
This is was lead to the recognition of the Uber programmer. A person with just one pair of hands, but with skills that spanned the whole process of creating software. Of course the productivity of a single individual is finite. Fred Brooks came up with the idea of the surgical team as a means of increasing the productivity of the Uber programmer, by utilising the hands of lesser programmers.
Kent Beck has suggested another approach were programmers communicate face-to-face and osmotically, whilst sharing common code, and programming in pairs. The idea is to achieve a brain "meld" across a number of individuals, banking on the idea that group make better decisions then individuals.
How ever you choose to tackle the problem, there are always a number of common characteristics:
1. There is a problem space and a solution space (working program). The difficulty is identifying both, and translating from one to the other.
2. This translation process is non-deterministic and complex, and for anything other than non-trivial problems it is seldom achieved without trail and error, in an iterative process.
3. The larger the number of people involved in the process, the higher the communication overhead. Software engineering does not scale, and the ideal team size is one person. Fred Brooks spoke about this too.
These basic points have been known for over forty years now. Fred Brooks touched on all of these. Yet we choose to ignore them because these facts don't map to our organisational structures and our management practices.
Paul.
