Gang Fang's Blog

NOTE1: Building upon existing systems that was developed by others is a vastly different experience from that of building from stretch or on something I know a lot about.

The project that I have been working on at the FBA coaching team seems small (i.e., how big is it when all I needed to do was replacing two Lambda functions triggers with a new one?), but it ended up taking longer and longer because there have been constant discovery of scope that was not identified during design. This additional scope was not due to business requirement changes but the incomplete identification of what needs to be done at a technical level during design. In that sense, a “low level” design is indeed necessary, which forces a closer examination of more granular, implementation level changes required to facilitate the high level design, or the architectural design.

There have been 3 such technical scope increases:

• Misidentification of foundational concept to be manipulated as “se”, however it was really the combination of “se” and “de”.

• Data models that needed changes were not identified. And corresponding data was either identified that was consumed by systems unrelated to the project.

• Interface changes that required downstream system changes.

Retrospectively, the first one is “supposed” to be hard to pin down because this is more of a issue of the design of the existing system, which is not explicit about important underpinning concepts. However, the last two were more on me rather than on external factors. The second one was due to largely the fact that I was new to Java and ignorant about the static typing nature of Java (i.e., data models are used whenever data is used). The third was caused simply because I wasn’t asking deeper and further questions.

By the way, I did miss one important aspect of high-level design, which is scalability and performance considerations. Potential scalability bottleneck should have been considered and tested during design instead of being looked at after all implementation was done. It was strange that I missed such an aspect given that I frequently encountered the need to use a specific architecture to combat scalability limit during my time in my previous team. My “excuses” for such a miss are 1) I was new to the team and was focusing mostly on the business requirements and understanding the existing systems. 2) I neglected the high-level questions I should have been asking. I should make sure in all my future designs, there should always be a non-functional requirements section and one dedicated to other important considerations, such as monitoring and operations.

NOTE2: Dividing work based on what have been pinpointed among collaborators (K and I) wasn’t entirely effective. It is a delegation model: K. worked on whatever I found and “ordered” him to do. Instead, delineating boundary of “ownership” could be a more powerful way to work together.

This delineation of ownership could have happened in such a way: I complete the high-level design, then ownership of the triggering system is assigned to me, while that of everything downstream is assigned to K. As I modify interface and the data model, K is prompted to investigate what those modifications entail for the downstream systems he owns. Subsequently, he makes corresponding implementation changes on his own. This model overall results in less ad-hoc communications on low-level details and one-way demand of work (aka me bossing him around), which I don’t consider the best.