This week I read the section “Craft over Art” which is found in chapter three of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section focuses on a software developer’s struggle in balancing their own personal want of making something with artistic merit and a client’s need of a product fulfills their requirements. The developer might add components that may be impressive but could also be pointless to or be an outright hindrance to the client’s wants. The developer may also want to polish up a project to a mirror sheen that deadlines would simply not allow for. And additionally, a software developer is a craftsman and not an artist. That doesn’t necessarily mean that a developer can’t produce something with beauty; a craftsman creates beauty by fulfilling a request to their utmost abilities. It just means that the client’s wants should be balanced with the software developer’s personal standards.

            The whole “Craft over Art” concept I agree with and in fact, I’ve thought of the concept on some level before through a practical point of view. Like why would I add features to software that wouldn’t benefit the user in some way? I’d just be wasting time I could use to polish up the existing components of the software. For example, If I were to work on a program that kept track of the transactions of a business and I added an option to play chess, that’d seem kind of pointless. If I really wanted to make a chess program, then I’d set that aside as a side project that I could do for fun. That doesn’t conflict with the “Craft over Art” concept since there have been plenty of craftsman who’ve worked on personal side projects in between their main commissioned projects. Even when just talking about software, I’ve heard of a fair number of programmers who’ve made little side projects like a game for example on their off time. And when working on main projects, I at the very least try to fulfill the minimum requirements so I can go back and polish it up as much as I feel the need to. But even then, there are time where the circumstances don’t allow for much polish so I just have to suck it up.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

The book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye covers multiple patterns important to being an apprentice. One of these patterns is called “Expose Your Ignorance” and centers around the issue of not knowing enough about a topic kind of important to the task at hand. Many people’s first instinct is to feign competence in order to avoid worrying their peers and suffer through embarrassment. The pattern instead suggests that people admit their shortcomings and ask questions. It might be hard to do but the benefits far outweigh the risks like learning important information sooner rather than later for example. Doing this has the added benefit of developing the learning ability through enforcing a “not knowing” mentality which just means to approach a situation if you were a novice. This mentality pushes an individual to broaden their horizons rather than becoming an expert on a single subject in a specific context. It also allows one to form strong relationships since this will be showing others your learning ability and flexibility.

I’ve had trouble “Exposing My Ignorance” for most of my life since again, most people’s first instinct is to feign competence. And of course, that wouldn’t work out since people would get mad at me for not knowing something and I’d end up barely learning anything. But I would still keep up this behavior until either late high school or early college mainly because there were some people in my life that would get mad at me for even asking questions. The reason why I broke out of that habit is because as I got older, I realized that there was so much I had no clue of doing. So, I started asking questions without caring what other people thought because I wanted to learn. For example, I wanted to learn to do my laundry so I just asked my mom to teach me and now I still do my own laundry. The same principle applies to software development; If you either don’t know something or aren’t confident in your knowledge on a subject, ask questions since there’s no real harm in doing so.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

https://blog.codinghorror.com/code-smells/

This blog post will center on code smells which was a topic covered in class fairly early on. The reason why I’m going back to it is mainly to refamiliarize myself with the subject since it wasn’t a major topic in class. Code smells are defined by the blog post linked above as general warning signs in code, hence the name. There are different types of code smells that signify different coding problems. For example, long comments, long methods, overly large classes, duplicate code, dead code, inconsistent naming, uncommunicative naming, et cetera. Keep in mind that these issues won’t necessarily stop a program from running, rather they negatively effect on the performance and design levels. Also, all of these different types of code smells share the common trait of not quite looking right when looking at a larger scale. So at first glance the code might seem fine, but given a closer look the flaws whether it be dead code, inconsistent naming, or whatever become readily apparent.

A code smell isn’t something concrete like a detailed recipe, it’s more abstract than that. It similar to a suggestion or a tip and can lead to improving code both on a functional level and a design level. Take for example, noticing the code smells of long comments and dead code which suggest removing the useless code and either simplifying or outright deleting the comments. This will make the code more readable which also improves it on a design level. On the other hand, noticing the code smells of duplicate code and long methods and correcting each issue accordingly will improve the code on a performance level top of the possible design improvements. All of the types of code smells that I listed earlier still hold true but they act as more of a general guideline. There are some scenarios in which some smell types blend together such as long methods and overly large classes to name one. Detecting code smells isn’t going to always be the same in that what someone is looking for will differ every time and the outcome will also differ every time. This process is kind of like trying to find freshly spoiled food; sometimes it looks fine and sometimes you won’t know what exactly you’re looking for. But what you do know is that something smells off and you probably don’t want to risk the chance of getting sick.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

https://thevaluable.dev/dry-principle-cost-benefit-example/

I’ve chosen to talk about a very simple design principle this week called “Don’t Repeat Yourself”, DRY for short. It’s a topic that is covered in this class according to the syllabus and I chose it since its similar to another topic I covered YAGNI in that they’re easy to understand design principles. The meaning is quite self-explanatory, don’t repeat code since if you need to change the behavior of a certain project, you’d have to rewrite numerous lines of code if DRY wasn’t applied. However, applying this principle to everything isn’t efficient either. Trying to apply DRY everywhere causes unnecessary coupling and complexity which also leads to more difficulty changing behavior. According to the link above, using DRY means emphasizes knowledge above all else. What it means by that is that when designing and constructing software, one should have the knowledge of when to apply DRY and when not to for the sake of the readability and efficiency of the code.

In that context, DRY reminds me of the importance of resources in a computer when running something. If you want something run faster, you’ll have to sacrifice more memory. And when you want something to have more memory, you’ll have to sacrifice more speed. Both are valid choices; it really depends on the needs of the software and the user. Say for example, I want to create a program that lists all numbers from one to 100 which I do by writing out a thousand lines of code in which each prints a number. However, if I implement DRY, then I could create an integer variable r and a loop which prints the value of that variable and increments it by one until r equals 100. But the case where I want to alter the behavior to list every odd number between one and 100 is where thing get a bit interesting. In the DRYless scenario, I can simply delete the lines of code that print even numbers. Yet in the scenario with DRY, I’d have to add a condition that skips printing variable r for that iteration of the loop. You have to sacrifice complexity for readability and vice versa. Though the choice is ultimately up to what works best in the current situation. Like in my example, the added complexity from DRY doesn’t really harm the readability, in fact it improves it in some ways, at least in my opinion.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.