Categories
Software Architect

Share your knowledge and experiences

From all of our experiences, including both success and failure, we learn a great deal. In a young industry like software development, disseminating this experience and knowledge is vital in helping sustain progress. What each team learns in its own tiny little corner of the world is possibly influential across the globe.

Realistically our fundamental knowledge base for software development, that is, the knowledge that is absolute and theoretically correct, is small compared to what is necessary to successfully develop a project. To compensate,we guess, rely on intuitive judgments or even pick randomly. In that, any major development project generates empirical evidence into what works and what fails. We’re gradually working through the permutations, which we want to apply back to industry as a whole.

At an individual level, we are all trying to grow and come to understand how to build larger and larger systems. The course of our careers will take us toward ever-increasing challenges, for which we want our past experiences to help guide us. Being there is one thing, but to get the most from the experience we often have to rationalize it. The best and easiest way of working through it is to attempt to explain it to another person.

The act of discussing something always helps to show its weaknesses.You don’t really understand something, until you can explain it easily. It’s only by putting forth our explanations and discussing them that we solidify the experience into knowledge.

Another point is that while we may have had specific experiences, the inferences we draw from them may not be entirely correct in the overall context. We may not have been as successful as we thought, or as smart as we wanted. Of course testing your knowledge against the real world is scary, particularly when you find out that something dear is myth, incorrect or was never true; it’s hard to be wrong.

Ultimately, we are human beings so not everything in our minds is correct; not every thought we have is reasonable. It’s only when we accept our flaws that we open up the possibility of improving. The old adage about learning more from failure always holds. If our ideas and beliefs do not stand the test of a debate, then it is better we find out now, than build on it later.

We really want to share our knowledge and experience to help the industry progress; we also realize it helps ourselves to understand and correct it. Given the state of so much of our software, it is clearly important for us to take every opportunity to share the things we know, what we think we know, and what we’ve seen. If we help those around us to improve, they’ll help us to reach our full potential.

'Coz sharing is caring
Categories
Software Architect

Start with a Walking Skeleton

One very useful strategy for implementing, verifying, and evolving an application architecture is to start with what Alistair Cockburn calls a Walking Skeleton. A Walking Skeleton is a minimal, end-to-end implementation of the system that links together all the main architectural components. Starting small, with a working system exercising all the communication paths, gives you confidence that you are heading in the right direction.

Once the skeleton is in place, it’s time to put it on a workout program. Bulk it up with full body workouts. This means implement incrementally, adding end-to-end functionality. The goal is to keep the system running, all the while growing the skeleton.

Making changes to an architecture is harder and more expensive the longer it has been around and the bigger it gets. We want to find mistakes early. This approach gives us a short feedback cycle, from which we can more quickly adapt and work iteratively as necessary to meet the business’ prioritized list of runtime-discernable quality attributes. Assumptions about the architecture are validated earlier. The architecture is more easily evolved because problems are found at an earlier stage when less has been invested in its implementation.

The bigger the system, the more important it is to use this strategy. In a small application, one developer can implement a feature from top to bottom relatively quickly, but this becomes impractical with larger systems. It is quite common to have multiple developers on a single team or even on multiple, possibly distributed teams involved in implementing end-to-end. Consequently, more coordination is necessary. And naturally, developers implement at a different pace. Some developers can accomplish a lot and in little time while others can spend a lot of time implementing very little. More difficult and time consuming efforts should be done earlier in the project.

Start with a Walking Skeleton, keep it running, and grow it incrementally.

'Coz sharing is caring