For this weeks blog post I will be looking into he Use Your Title pattern. The context behind this one is that as a result of your dedication to learning, you’ve been hired or promoted into a position with a title containing the words senior, architect or lead. The problem that will arise from this is that the job title doesn’t actually match what you see in the mirror. When you introduce yourself into this new setting you feel as if you have to apologize or explain the difference between your skill level in your actual job description. A solution to this is that you shouldn’t allow the title to actually affect you. Its just a distraction that should be kept on the outskirts of your active conscious. Use the title only to gauge your organization not yourself. Don’t get fooled by a fancy title, your mother might think you deserve it but the impressive title and responsibilities mean your apprenticeship is over. They serve only to remind you that there is a shortage of craftsmen in the industry. While on the other side of this coin is an unimpressive title despite the fact that you may have surpassed your colleagues. The frustration that comes from a lack of recognition should remind you that the industry has a problem. Using this as a measurement of your own organization and fitting it rather than allowing the frustration to bog you down. Another variant that comes from this theme is the informal versus formal titles. For example you may have grown into a position of authority on your own team despite the formal title remaining. These informal titles can be hard to actually ignore, because they are constantly reinforced by peers and colleagues. These titles remain even if they conflict with your own self assessment, keeping with your mentors and kindred spirits will be critical to keeping you grounded in reality. The recommended action to all of this is simply write down a long and descriptive version of your job title. Making sure it accurately reflects what you really do at work and your skill level. This is again another pattern that I agree with and can see myself using in the future.
For this weeks blog post I will be looking at smoke testing.
A smoke test is used to describe a suite of basic tests that verify that the major features of an application are working properly. A most common se of this is simply to determine whether a build is stable and ready for further testing or a final check before you submit something. The result of this testing is used to decide if what you built is stable enough to proceed with even further testing. The terminology behind the name comes from a similar type of hardware testing in which the device passed the test if it did not catch fire the first time it was turned on. The testing covers most of the major functions of the software but none of them in extreme depth. The result simply is whether or not you must go deeper or not. If it fails you stop further tests and try to fix what you already have. This testing helps expose integration and other major problems early in development cycles. It can be conducted on both newly created software and enhanced software. A smoke test is almost always performed manually with some help of automation tools or scripts but if the builds are prepared frequently automated smoke testing is the best to use. After an application becomes more developed and mature in a sense with more functionality the smoke test will need to be made more expansive. Sometimes even just one incorrect character in the code could render an entire application useless. The advantages of this smoke testing expose integration issues and helps you uncover the issues early.
For this week’s blog post I will be taking a look at another antipattern, another very common AntiPattern that creates maintenance nightmares. It usually takes the form of several similar segments of code that are interspersed throughout the software project. Programmers who are learning how to develop software who are following the examples of more experienced developers usually fall prey to this unwillingly. They do this by modifying code that has worked for them before in a similar situation and they think by potentially customizing it to support new data types they can get by but this causes code duplication which may cause positive outcomes but long-term problems. Symptoms of this antipattern include the same software bug that reoccurs throughout the software despite local fixes, lines of code increasing but overall productivity not being affected. Essentially this antipattern re-uses code that you may or may not need adding to your lines of code without any actual assistance being provided from the length. The most common cause of this is a lack of abstraction among developers who are often accompanied by a poor understanding of inheritance, composition, and other development strategies. And is most likely to occur when people are unfamiliar with new technology or tools as a result, they take a working example of something and modify it, trying to adapt it to their specific needs. Some solutions to this involve white box reuse through the developers extending systems primarily though inheritance. On the other hand of this black box reuse has other advantages such as the object is used as-is, through a specified interface where the client is not allowed to alter how the object interface is implemented. In a way this antipattern is very similar to spaghetti code but spaghetti code is not structure for easy component reuse because of this Cut and Paste Programming is the only means available for reusing preexisting lines of code.