The section titled Find Mentors discusses finding people in your field who are seasoned and have a lot of experience to offer, and to reach out to these veterans of the field and try to gain from them what knowledge they have to offer. It is a simple idea, but as the text explains, it is intimidating to just ask someone to offer their services and mentor you. It is a lot to ask, and not everyone is up for it after all. Besides, it is challenging to know who is even a good mentor, and who is not.
I consider many of my professors at Worcester State mentors to an extent. However, I wouldn’t say I’ve ever had the kind of mentor-ship detailed within the section. I can definitely relate to the anxieties listed about reaching out to someone. It can seem weird and uncomfortable. I suppose it is just a feeling you have to conquer if you want the best for yourself, however. After all, nobody else is going to ask for you.
From my perspective, Find Mentors is such an important pattern because there is a limit to how much most people can learn independently. There is such a huge advantage to having a resource like someone who has been through all the challenges you are facing and can solve some of the problems that come up. I hope that in my future I have the chance to meet someone who can offer me these advantages. Actually getting into the field is a huge hurdle, and having someone who has been through it and could coach me on how to navigate it would be incredible. It is just something I am going to have to search for.
Overall, Find Mentors seems like one of, if not the most important apprenticeship pattern I’ve read about and discussed so far. After all, finding a compatible mentor that is willing to dedicate the right amount of time for you would result in huge growth and development. It is hard to obtain this ideal, but it is something worth striving for.
Michael Bolton’s post How Long Will the Testing Take? on his blog DevelopSense goes into depth on how long testing takes. Bolton claims good software testing as a process takes just as long as development, because the two are actually interwoven as processes and should happen simultaneously.
I think a lot of people brush off testing systems and software because of the idea that it takes additional time and can make the release of a project come later. However, as Bolton states, testing actually occurs simultaneously to development, as things are tested as they are implemented into the system to make sure they interact correctly. With this in mind, the program should be fully tested not long after it is completely developed. It doesn’t really cost much extra time, just the extra costs of developing tests. However, doing it this way also allows you to fix issues that come up along the way, before they become larger issues.
In some of my earlier programming classes, students were often encouraged to write one test and make sure it works before moving onto the next test. We were also encouraged to write tests after every method we made in our programs. In a way, we were clearly being prepared for this approach to development and testing, and it was clear even then why it is a good way to work on a program. It is logical, as incremental development seems a lot safer. You avoid getting overwhelmed with errors and issues that all compound on each other at once when you write your tests this way.
The blog post also covers the silliness of the question of how long testing will take. If your developers and testers are working together and doing what they’re supposed to, testing will finish as soon as development does. Although you can test the system in post-production, it is entirely optional, and is only done with good reason. So in the future, if I am ever managing the development of a system, I will be able to recognize what the testers are doing and ask more productive questions.
In the post Grouping Components by Use Case, Robert Annet discusses a strategy he uses when making context diagrams. After determining the use cases of his program, the components involved in each of the seven use cases are divided into groups within the diagram with different colored barriers. Structurizr, the web application Annet used for his diagrams, allowed him to filter the diagrams by the use cases. This makes observing which components are involved even easier visually.
The benefits of using this strategy of dividing your context diagrams into use cases is clear if you are working with a program that is complex enough to warrant it. A complex program in this case being one with a lot of different components which all are involved in several different interactions. If you have to make changes to a certain interaction withing your program, you can look at the components involved in the use cases and identify what you have to change to make the desired effect. Since your program has a lot of different and interlaced interactions and components, using these use cases and filtering your diagram into smaller parts makes it easier to understand the interactions and whats happening with the involved components without being overwhelmed by a ton of different components that don’t have any involvement. In my opinion, it is much clearer when you only have to see two or three components when you want to change an interaction in the program.
Using this strategy can also help you find other issues or reliances in your program. For instance, you may find that most or all of your use cases use the same component. Since this component is so integral to the interactions in your program, it is likely not one you are going to want to change much. This strategy also can help you find components that are not being used in your program, and thus may be unnecessary or you may need to reassess your use cases.
Overall, I thought Robert Annet’s idea of dividing programs into different use cases is very interesting and obviously useful as a concept, so I’m sure I’ll use in the future. Whenever you are dealing with a large enough system, you should consider looking at the diagram from this angle to see if you can identify any problems or vulnerabilities.