Principles, Practices and Processes
The three Ps that I want to treat are best taken in the reverse order. The reverse of the listing in the title and the reverse of the importance to which many practitioners put them. Process is the leader for software practice within teams from which follows adherence to principles.
More often than not the absence of process in any guise, formal or informal, means that the team members work in a process vacuum. Obviously it is not a mandatory requirmement to have formal, documented processes in order to successfully develop software. All you need is a small, tight-knit group of very smart software developers. Sure.
For one thing, the informal processes of a small group do not scale well. It is all good and well to decide that good practices can be passed on by word of mouth and the exchange of information between seasoned and novice developers exchanging verbal and nonverbal cues. However the communication overhead, the fragility of memory and the difficulty in attracting and retaining that magical, high-calibre of staff (if they even exist) makes the trite statement that formal, documented processes are unnecessary a nonsense.
In reality, most hires are well meaning, hard working, technically adept and competent in their fields of experience. The cited norm of hiring exceptional candidates is unrealistic at best in a tight job market where your competition is offering the same salary packages and perks (more on this later).
The two important facts that are often ignored by technical professionals who are running the software development factory in the organisation is that firstly they are likely bound by a fiduciary obligation to capture organisation knowledge and secondly should consider the importance of balanced teams.
If not that manager personally then their boss (the CIO or CTO) has or should have a policy for knowledge management. The sustainability of any organisation depends upon its capacity to remember how to maintain and develop legacy and newly-developed systems.
One of the biggest mistakes is to ignore the documentation and maintenance of legacy systems while a replacement is being rolled out. Nominally in a short timeframe, to provide all of the extant functionality of the dinosaur model and more. The truth usually falls far short of the ideal and the new system will be delivered late, if at all, lacking basic functionality.
Balanced teams are all about finding the right people to work on projects together. Usually a gender, age and background mix adds strength as negative monocultures are avoided while positive synergies emerge. In this respect, balanced teams need high performers and steady workers, high-level designers and low-level hackers(*), planners, doers and influencers.
Process offer guidance for new inductees and set boundaries, preferably nonprescriptive guidelines, for novices and experienced practitioner alike. To define the set of practices that the team uses to build and deliver the solution.
The design and construction of the solution is less a mechanical exercise than one which is by its very nature creative. The entire software development lifecycle involves negotiation and compromises (more later). By the people, for the people. The modern approach to software development is to apply object-oriented and patterns design. At a certain level the business objects and domain ontology can be understood as an ensemble of collaborating objects.
Pattern poetry. Emergent systems.
The day-to-day software development is sharply focussed on the The Principles of OOD that have been communicated so well by Robert Martin. Uncle Bob to his friends and admirers. To him and Martin Fowler I defer on many issues in discussion with my peers and colleagues as I hold them in the highest respect (more later).
The gist of Agile development is eminently supportable (eg. test-driven development) even if some of the practices are debatable. More later about Barry Boehm, David Parnas and the ascendency of the traditional approach of lore. By recent graduates not forgotten; never learned that there is little new (more later).
Building on the seminal work by Grady Booch in bringing object-oriented design into the mainstream after decades of being perceived as a niche technology or a novelty. Where the C++ language invented by Bjarne Stroustrup made OOD a practical reality even if the market-driven successors Java and C# promised so much more while delivering, in many ways, so much less (more later).
(*) Hackers not crackers. See A Brief History of Hackerdom by Eric S. Raymond if you seek clarification.
More often than not the absence of process in any guise, formal or informal, means that the team members work in a process vacuum. Obviously it is not a mandatory requirmement to have formal, documented processes in order to successfully develop software. All you need is a small, tight-knit group of very smart software developers. Sure.
For one thing, the informal processes of a small group do not scale well. It is all good and well to decide that good practices can be passed on by word of mouth and the exchange of information between seasoned and novice developers exchanging verbal and nonverbal cues. However the communication overhead, the fragility of memory and the difficulty in attracting and retaining that magical, high-calibre of staff (if they even exist) makes the trite statement that formal, documented processes are unnecessary a nonsense.
In reality, most hires are well meaning, hard working, technically adept and competent in their fields of experience. The cited norm of hiring exceptional candidates is unrealistic at best in a tight job market where your competition is offering the same salary packages and perks (more on this later).
The two important facts that are often ignored by technical professionals who are running the software development factory in the organisation is that firstly they are likely bound by a fiduciary obligation to capture organisation knowledge and secondly should consider the importance of balanced teams.
If not that manager personally then their boss (the CIO or CTO) has or should have a policy for knowledge management. The sustainability of any organisation depends upon its capacity to remember how to maintain and develop legacy and newly-developed systems.
One of the biggest mistakes is to ignore the documentation and maintenance of legacy systems while a replacement is being rolled out. Nominally in a short timeframe, to provide all of the extant functionality of the dinosaur model and more. The truth usually falls far short of the ideal and the new system will be delivered late, if at all, lacking basic functionality.
Balanced teams are all about finding the right people to work on projects together. Usually a gender, age and background mix adds strength as negative monocultures are avoided while positive synergies emerge. In this respect, balanced teams need high performers and steady workers, high-level designers and low-level hackers(*), planners, doers and influencers.
Process offer guidance for new inductees and set boundaries, preferably nonprescriptive guidelines, for novices and experienced practitioner alike. To define the set of practices that the team uses to build and deliver the solution.
The design and construction of the solution is less a mechanical exercise than one which is by its very nature creative. The entire software development lifecycle involves negotiation and compromises (more later). By the people, for the people. The modern approach to software development is to apply object-oriented and patterns design. At a certain level the business objects and domain ontology can be understood as an ensemble of collaborating objects.
Pattern poetry. Emergent systems.
The day-to-day software development is sharply focussed on the The Principles of OOD that have been communicated so well by Robert Martin. Uncle Bob to his friends and admirers. To him and Martin Fowler I defer on many issues in discussion with my peers and colleagues as I hold them in the highest respect (more later).
The gist of Agile development is eminently supportable (eg. test-driven development) even if some of the practices are debatable. More later about Barry Boehm, David Parnas and the ascendency of the traditional approach of lore. By recent graduates not forgotten; never learned that there is little new (more later).
Building on the seminal work by Grady Booch in bringing object-oriented design into the mainstream after decades of being perceived as a niche technology or a novelty. Where the C++ language invented by Bjarne Stroustrup made OOD a practical reality even if the market-driven successors Java and C# promised so much more while delivering, in many ways, so much less (more later).
(*) Hackers not crackers. See A Brief History of Hackerdom by Eric S. Raymond if you seek clarification.
posted by Daniel Berinson at 10:40 PM
0 Comments:
Post a Comment
<< Home