coder . cl

Few people is capable to understand the meaning of working in teams. Among other things, on a team we need to set the proper communication channels. My last assignment as employee of a company was Software Architect for a set of projects for a new client on the company. I was in need to do research about the platform where we were working on and I don’t mean the third party pieces, such as language, application server and related stuff, I mean the enterprise application. It was poorly documented, so we need to harvest the code seeking for answers.

As result, we got a nice architecture design, very applicable to most problems present on the platform. Also, I was capable to answer many questions about the enterprise application. Many of those answers were made based on reverse engineering the source code, tracking every step and tracing component execution. Each member was capable to read some books that we recommended with the Project Manager and understand the third party software, like Google Web Toolkit and Apache FOP. The Project Manager was a good leader guiding the team to the right direction on what to read and how self taught those technologies, while I was doing the proper research, then we got a good team response, and being considered as a good provider.

The key on success was nobody was afraid to ask about the enterprise application, so each member of the team was capable to understand how to interact with those layers that were not accessible as source code — like a black box — and that everyone on the team was responsible of learning the techonologies related to the team work: "read that book", "read that blog article", "take a look on this specification" and some other phrases were common on that team, so everyone was capable to understand their own task.

Most questions were channeled directly to the project manager, then I he was capable to answer, the problem was solved on the fly. In other case, the problem was delivered to me as software architect. Also, team members were capable to ask me directly. Also, most questions were made on SCRUM sessions, and few ones were asked outside of those SCRUM sessions. Few books on Software Architecture, JavaEE Design Patterns, Design Patterns and Architectural Patterns, bring us a wide perspective on how to solve most problems for the kind of components that we were developing. So, most problems were found on the black-box-like enterprise application, since we were having few referrals.

Even if one software engineer was considered — before joining the team — as an NNPP or bad programmer, on the team we got a good result. I agree with Phillip G. Armour in his article "In Prise of Bad Programmers", where he treat this problem as an advantage to make stronger teams:

Sometimes the teams are not made up of all superheroes and when the team asserts itself to overcome some limitation, even with its own personnel, it can become better than it would have been without limitations.

All team members were capable to learn about the enterprise application without the pressure of of not having someone supporting them and fear to commit bugs into the VCS. The were constantly improving their skills, by different reasons, but everyone was learning. As spotted Pete Godlife on his article "Live to love Learning":

Your motivation might be to keep yourself fresh, to sharpen your existing skills or simply to satisfy your natural curiosity. Or the reason might be more mercenary: to strengthen your employability, or allow you to move into a programming field you are more interested in.

conclusion

On every new application which requires new components or maintenance, we need to research it, we must invest time looking on how it works, how affects any change and how we can contribute to improve its construction. Analysis capability is learned along the time and acquired by studying applications and code, you can not request a 100% successful development to someone that do not have the proper guide on a large enterprise application, you need someone doing research on it, doing reverse engineering if it is not documented and let the people learn from that member that have the advantage, even if the application looks like this one — which fortunately isn’t the case in this post.