Summary of thought in development process, and farewell to TTC

My last two days with TTC. Having this written down, and farewell to the team.

At a very high level, software development processes and methodologies can be abstracted as means to help development team to:

1) Resolve right problems;

2) Resolve right problems in right ways;

3) Resolve right problems in right ways under resource restrictions.

Here are my comments and suggestion from those angles.

1) The Right Problem

Before we can resolve a “right problem”, we need identify and understand it first. Three key roles need to be in place to succeed:

Domain Expert:

With deep understanding in the business domain, Domain Expert has close relationship with customers, knows what customers want and what they really need, and understands the value of each required feature as well as the severity of each reported issue.

Technical Stakeholder:

Often architects or team leads, Technical Stakeholder oversees the technical aspects and quality of the system, can identify “Architectural Significant Requirements”, can provide best possible cost estimation, can raise non-functional requirements implied by functional requirements.

Product Owner:

One who finally defines the “right problem” and determine when the problem should be resolved based on its value and cost.

All three roles need to be clearly defined and closely worked together. The better they collaborate, the higher chance for the “right” product being built.

2) The Right Way

Having “right problem” identified and understood answers only the question of “what”, at a relatively high level. The detailed “what” and the actual “how” are dynamic in nature and uncertain at the beginning. Collaboration between team members and the roles described above should continue till the end of the development cycle, this includes user story elaboration, architectural design sessions, modeling, prototyping, feedback collection and task reprioritization, etc.

* * *

Regardless of what development process a team uses, I believe in that “best software are built by best people” and “High quality of systems can only result from firm enforcement of essential principles and best-possible, empirical and consistent guideline and practices in design and implementation”.

I have heard tasks like “refacoring” mentioned in daily scrums. I do think this term is sometime misunderstood and overused. Now, if a developer doesn’t really know too much about the concept and techniques of refactoring, how can he be expected to refactor correctly and effectively? If one hasn’t had chance reading the “Design Patterns”, how can we expect design and modeling ideas involving patterns can get well communicated and understood?

No one is born with all required knowledge and skills. However, after a team is formed and normed, and after a process is adopted, we should identify the “common ground” of the least required knowledge and skills, and encourage and push the team onto the ground.

We’ve been talking and embracing the Domain-Driven-Design. To some extent, DDD is just kind of advanced OOAD which requires solid understanding to the OO basis. If OOAD is not strong in team, we should get more training on OO first so that the DDD practice can be smoother and not just played by a few people.

One example, which I was very much benefited---one of the most important points in book “Code Complete” is that the key to software design and implementation is to “manage complexity”. We know we can’t eliminate complexity but we can manage it well. If we understand this well, we understand deeper in class design principles, componentization, layering, code smells, SOA, and so forth.

We all know that IT guys who wish to survive and advance in career need keep their skills sharpen, knowledge broaden and deepen. An environment which encourages people learning is good for both team (company) and individuals. A company I previously worked had a policy encouraging everyone to spend an hour each day in work-related studying. I found that was a good idea.

Also, my comments on Pair Programming----I don't really believe it improves productivity, nor do I think it improve code quality much; however, I do consider pair programing a very efficent way in mentoring and peer knowlege transfer. We should use it sometimes.

* * *

Now, acknowledging that there is no such ideal world in which everyone has right level of required skills and knowledge with no miscommunication among peers and different roles. Disciplines come to play.

Integrity and consistency are very important to software systems, regardless of their sizes. There can be many approaches to resolve a same problem. While it is important to choose the most elegant and optimal solution, it’s also critical making trade-offs sometime in order to maintain the integrity and consistency.

To build a system with good quality takes huge effort; to worsen or even crash a system is much easier. We should not leave “broken window” and fix them as soon as possible (about “broken widow”, sometimes called “technical debts”, and is discussed in book “Programmatic Programmer”).

A team requires technical discipline, which calls for strong technical leadership and firm enforcement on agreed guidelines and practices.

In theory, a technical team lead who leads a team with five members requires 50% of his/her time in overseeing technical issues, communicating internally and externally, and enforcing the development disciplines.