Some helps I can offer you and you can offer me
Pair programming sessions
Many consultants believe that pair programming is the universal solution to any problem that a software project can have.
- It spreads the technical skills
- It spreads the functional knowledge
- It builds the team
- It’s fun
— Victor Rentea, “Brainstorming a Clean, Pragmatic Architecture”
Shared set of values
… high-functioning teams must have a shared set of values.
Teams that don’t enjoy a shared set of values are unstable. If each member of the team does what is right in their own eyes, without considering the values of the team; then they don’t actually comprise a team. Instead they will behave chaotically, and work at cross purposes to each other.
I would like to request for you to make me be a part of a team who tries to keep their codebase clean, and who constantly refactors the codebase to keep it clean and maintainable.
If you do not have a team like that, I would like to request to be part of a team whose team lead tries to keep the codebase clean and maintainable.
If you do not have such teams, and if your codebase is not yet too complex for me to handle, I think I will have to step up and request to take the responsibility of being a team lead — to become a foreman or an assitant coach of a team, as described by Uncle Bob Martin in his blog post “Oh Foreman, Where art Thou?”. I’m begging you to consider appointing someone who will be responsible for the state of your codebase, so that you, and your team, and me , will not suffer later on. If you cannot find anybody else, you can appoint me. I will accept the responsibility if the codebase has not yet gone over a rotting state that my current skillset can handle. I would just like you to know that I have no experience being a team lead yet, but if you appoint me I will do my best to handle that kind of role. Also, I think I will become an effective team lead only if I am involved in the coding tasks. So I need to spend half of my time coding, and half of my time reviewing code or pair programming with the team.
In case you fear that I’m an autocratic kind of person, and so is not suited for this role I’m describing…
… I read the book “How to Win Friends and Influence People” many years ago, and it had a great impact on how I view other people, so I’m not clueless about handling people so as not to hurt them very much during code review and pair programming. But I might have already forgotten many of the good ideas from that book, so I’m also open to suggestions on how to handle other programmers, if given a chance to handle them.
Also, I like many of the ideas being espoused by libertarians, who likes freedom so much. That’s another thing I can give as evidence that I don’t have an autocratic kind of attitude towards other people.
I can do compromises if needed; or turn from my initial decisions when I discover that they are wrong.
And I know of Kent Beck’s “Implementors rule”:
The Implementor’s Rule is that implementors rule. If you can’t agree and you don’t want to work together, agree a scope and whoever cares most goes and works within that scope.
I can also do with a one man team — me alone working on a small or medium sized codebase. I would just like to ask that there be some process in place where I can raise a flag if I’m stuck with a problem; and be able to ask any programmer from other teams for possible solutions of the problem.
Thank you so much
Single architectural vision
I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.
Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds.
… I will certainly not contend that only the architects will have good architectural ideas. Often the fresh concept does come from an implementer or from a user. However, all my own experience convinces me, and I have tried to show, that the conceptual integrity of a system determines its ease of use. Good features and ideas that do not integrate with a system’s basic concepts are best left out. If there appear many such important but incompatible ideas, one scraps the whole system and starts again on an integrated system with different basic concepts.
Frederick P. Brooks, Jr., “The Mythical Man-Month”, chapter 4
Fred Brooks, it seems to me, is suggesting that it’s best if a codebase follows a single structure or architecture.
I would like to request that…
If the architecture of the codebase I’ll be working on is obvious on first look, and if it was already decided by the team to keep following that architecture, then no request coming from me regarding this.
If the architecture of the codebase I’ll be working on is not obvious on first look (because there might be two or three competing architectures), I would like to request for the team lead of software development to explain his architectural vision for the codebase. By “architectural vision” I mean the direction he wants the codebase to follow moving forward. This will help me see where the codebase is supposed to be going, and to have good knowledge on how I should write my code as to not deviate from his architectural vision.
I would like to note that when I use the words “team lead”, what’s in my mind is someone who is also working on the project hands-on, because in that case the team lead truly knows the codebase and its problems, and so it will be hard to argue against his architectural vision. If he is not hands-on, but his architectural vision still makes sense, then I will still respect his architectural vision.
If the codebase does not have an architecture (it’s a mess because there are hundreds of competing architectural ideas within the same codebase), and no architectural vision is in place, then I would suggest that someone or sometwo be assigned to look for an architectural vision that will be followed from a set time in the future and forwards. If I am choosen to be the one who will set the architectural vision for the codebase, I would like to ask the client (or maybe the non-technical coach) that it be made clear to the team why a single architectural idea is needed — that is, to make the codebase easier to manage or maintain* in the long run — so that they will not rebel against me , and so that my will to design will be reinforced (it needs reinforcement because I am leaning towards the introvert side of the Introvert-Extrovert spectrum).
Depending on the complexity and size of your codebase, it might take a few months of working on it (because I’m not a genius) before I can find an architectural vision which matches with the current state of the codebase — that is, an architectural vision that will not require a big overhaul of the codebase, but still makes it maintainable.
Also, because I know that someone out there is better than me at doing things, I am ready to step down from the position of being in charge of the codebase if someone more competent than me is needed to take charge of it.
Also, if I see someone in the team who has design sense, I will try to make him a co-coach and give some of the responsibilities that I have, so that someday I can leave the project without worrying that it will go to a mess. Or, if I will not leave, at least I have contributed to the carrer of someone who might become a programming coach someday — because I think we really need lots of programming coaches these days. Even I need a programming coach (I might be making mistakes which I do not know are mistakes). I hope I can find a coach someday.
* “The true cost (80%) of software lies in its maintenance, not in its initial development.” - time 03:17 of “The Art of Clean Code” by Victor Rentea
Please note that if there is a plan to scrap or replace the codebase after a year or two, there might be no need for this architectural vision thing. It is most needed when the system is expected to be maintained for 10 or 20 years more, with lots of requirement changes during those years.