Pattern 3 – The Long Road

I thought the title of The Long Road would make for an interesting pattern to read, so I chose it for this particular post. This pattern describes the path that a craftsman will have to take to become a master throughout their career. This is specific to becoming a master of software development and not particularly for what is traditional success in a career path that we as newly graduating software engineers are “expected” to follow.

For this reason, I honestly disagree with the general idea of this pattern completely. The pattern does make it clear that this is the path specifically for people whose life goal is to become the best at software development and does not seek anything else out of a career in software development. I don’t see this as the norm, or generally good advice in any regard. I also feel that it is important to state that this is merely my opinion, but also one that I strongly believe in. From everything that I read about software developers who stick strictly to software development throughout their careers, they often burn out but also feel that it is too late in their careers to do anything else. These are engineers in their late 40’s and 50’s who have been working for the same company for well over a decade and feel that their knowledge in software development is so narrow because of a lack of exposure to other tech and other business domains. While this is not always the case, this is just what I’ve read and have been exposed to personally.

The pattern also preaches how admiral it is to stick to this strictly developer mindset and how money and promotions should not be a focus for you. While I think that this is important to not be the only focus in a career, this is just silly. Promotions and salary should not be a measure of your success but they should be something we all seek, and a goal for people to strive for throughout their careers. The way this pattern is worded, it seems to try to even nudge readers away from positions like architects where you aren’t specifically writing code on a day to day basis. It wants readers to avoid big picture positions and exclusively stick to coding. There is always more to learn in coding and we should all do something we love, but coding should not be the only aspiration for our careers. For that reason, this article has not changed how I will approach my career, but possibly reinforced the goals I previously had.

Advertisements

Exploring Decision Tables for Software Testing

For this week’s blog post, I decided to choose a subject that would give me a little more experience with a technique for black box testing, or developing tests for software without direct access for the code for a particular application. This way, the tests are created with a bigger focus on the business logic instead of particular barriers that may arise within a programming language or the overall stack of the application. I found an article on softwaretestingclass.com that covers the usefulness of decision tables in regards to software testing. The article discusses how to use decision tables as well as why they are such an important tool for black box testing. The article also mentions other examples of testing techniques for black box testing.

The author, Venktesh Somapalli, provides an example of a financial application where there are two possible conditions for a user, repayment within a term, or moving on to the next term of a loan. Somapalli goes through the steps that a tester may consider constructing a decision table for this particular application. The table for the decision table technique is based on conditions either being true or false, so all outcomes are absolute. This means that there are there should only be one outcome for a set of conditions. However, the reverse of this is not true, there are can be more than one set of conditions that have a particular outcome. In the example in the article, if both of the conditions are true or false, an error message is the outcome. On the other hand, there is only one set of conditions that processes money, and one that processes the loan term.

My favorite part of this testing technique is that it is inherently non technical due to the nature of black box testing and the simplicity of the concept. This means that non technical people within a business can understand and even develop test cases using this technique. As Somapalli points out, this technique is also versatile because it can be applied to any set of business logic. Somapalli also notes that decision tables are iterative meaning that if any new conditions are added to the logic, the existing table can be reused and revised to consider the new logic without a complete reconstruction. I definitely agree with his arguments for the usefulness for this technique. I have used this technique in the past and before reading this article, I didn’t even consider the powerful nature of this versatile strategy. I will definitely continue to make use of this technique when developing test cases whenever possible throughout my career.

Link to the original article: https://www.softwaretestingclass.com/what-is-decision-table-in-software-testing-with-example/

DRY/WET

What is DRY code? I’ve heard the term before in some tutorials but never knew the meaning behind the phrase. I figured if I keep seeing it, it must be important. After searching around the web for a bit, I finally found a great article on what DRY/WET code is on softwareyoga. The article explains what DRY/WET means, the advantages of DRY code, and the precautions to take when considering this principle. DRY code means “Don’t Repeat Yourself” and WET means “Write Every Time”. Obviously, DRY is the one everyone should wish to achieve for most cases. The advantages that the article goes through are maintainability, readability, reuse, cost, and testing.

DRY helps make code more readable because logic is not repeated throughout multiple classes. Instead methods/functions are called and what is likely hundreds of lines of code is represented by a few function calls. Readers of the code base can find the logic, read it once, and understand how it functions. Then when they see it implemented, they do not need to double check that the logic is the same. If code is WET, the logic will be re-written entirely, forcing readers to ensure nothing is different in each implementation.

Reuse and Cost go well together as reuse lowers the cost of development. When reuse is the goal/option, cost is inherently lowered. These go along with maintainability as reuse means that the code is properly maintained. If code can be reused, this means that small changes to the logic are less likely to cause problems. There would also be less time spent refactoring code in the future if previous implementations are written with DRY in mind. This means that less time, and developers are needed to maintain a long-lasting codebase.

Testing is simple, if the source code is written DRY, writing the tests DRY only makes sense. This also makes tests easier to write, and easier to change in the future.

The cautions for DRY expressed in the article are rather self-explanatory. One of the pre-cautions is to not over-DRY your code. Basically, this means to only use DRY when it makes sense to use DRY. If the code doesn’t need to take advantages of what DRY offers, it likely doesn’t need to be written with DRY in mind.

DRY is a great principle to follow when writing code. It teaches good practice and can be applied to most of the design patterns that we are learning. Most of the design patterns build upon each other and do so to keep code DRY. Implementations are written without rewriting logic and instead only require simple method calls. I hope to keep my code DRY in the future. If I do so, I will find it much easier in the long run to both add to, and learn from my previous projects.

Here is the link to the original article: https://www.softwareyoga.com/is-your-code-dry-or-wet/