Uh Oh! Spaghetti Code!

Hello, once again my fellow readers! I am sorry to report that this will be my last blog post for this semester and in turn this class. Continuing with my trend of Antipatterns today I will talk about a delicious Antipattern, Spaghetti Code.

SPaghetti code is the Antipattern that everyone first falls into when learning how to code a new language, learning a new coding tool, or learning how to code in general. Spaghetti code is the Antipattern representing code that has very little software structure. As a result, this leaves the code with a lack of clarity or direction, even to the original developer. This is the classic moment where you uncover code from some time ago, sit down, look at it, and go, “What was I even trying to do here?”

It can be quite easy to identify Spaghetti Code. Simply look for methods being very process oriented. Object implementation will also dictate flox execution. You will see minimal relationships between objects. You will see a very predictable pattern of object use.

Spaghetti Code can result in many consequences. Spaghetti code results in a program with diminishing returns. If Spaghetti code is mined, only part of the code will even be suitable for reusable if any of the code is reusable at all. As well, maintaining the code will result in being much more wasteful and a diminishing return as well. It will be more practical and less wasteful if a new solution is developed. Spaghetti code is so detrimental, it can even remove the benefits of object-oriented design.

To fix Spaghetti Code, you can refactor your code. Refactoring code is a natural and excellent way to maintain your code and is a wonderful way to increase performance. Code refactoring first must achieve a sufficient structure. Then, performance critical code must be identified and then structure compromises must be implemented as to enhance performance. Of course, the best way to get rid of Spaghetti Code is to prevent it in the first place.

As I was reading this, I knew that this is something that I could apply this almost immediately. In my next semester, I will have to work in a team and build off of an existing program. This Antipattern will stay with me and I definitely will see how I can work refactoring into the process to ensure that no Spaghetti code will remain. I have a sneaking suspicion that refactoring will be an idea that if implemented, will be able to squash many different Antipatterns that show up or are already lurking.

Well folks, this going to be my last blog entry for this semester. Thanks for reading and learning along with me (or watching me read). Until next time, have a wonderful day!

 

I Know Halloween Was A Couple Months Ago But…

Hello, again my friendly neighboorhood readers!

This week I have been again been reading up on those crazy Antipatterns I discovered week. As you can probably tell by the title, the Antipattern I am writing about this week is a Halloween themed Antipattern. I know it’s a little late but today’s Antipattern is the Poltergeist.

A Poltergeist is a class that has a limited role to play or limited responsibilities in a system. This practice adds unnecessary abstraction and their short life cycle means more wasted resources. Poltergeists normally appear to initiate some other action of a class that has a more permanent status. A Poltergeist is easily identifiable as they will typically bear the “_manager” or “_controller” title in their name. The main three disastrous effects of the Poltergeist Antipattern is a waste of resources every time they are called, they utilize redundant navigation paths, and the clutter the object model, getting in the way of proper object-oriented design. If a Poltergeist Antipattern is left alone it can result in such occurrences as transient associations, stateless classes, redundant navigation paths, short duration, temporary classes, and objects, and single operation classes. Some typical causes that lead to a Poltergeist Antipattern manifesting are a lack of object-oriented architecture, using the incorrect tool for the job, and of course, a specific disaster such as management incompetence.

Now how do we fix this Poltergeist problem? Well, they gotta go. Of course, once the Poltergeists are gone, the functionality they had must be replaced with an adjustment to the architecture. Another solution is to utilize the 80% solution that we discussed in the post discussing the Blob Antipattern.

Now, I do not know about you reader, but I believe that this is definitely an Antipattern that every programmer falls prey too, especially when they are beginning. I can think of many programs that I have many over the years that have had at least one Poltergeist stalking around in them. This does make me rethink how I will program in the future. While the programs I may write now do not need any real optimization, in the future, optimization is going to be a required skill for me.

Well, that is it for today readers. Have a good week until next time!

I’m Sorry, an Anti what now?

Good day once again my fellow readers! In my readings this week, I discovered something that I had never heard of before, antipatterns. Now that is quite a striking name and it piqued my interest in this subject. So today I will be talking about software development antipatterns, particularly the Blob.

First, let’s discuss what an antipattern even is. An antipattern is simply just an industry term for a common solution to a problem that generates negative consequences. what antipatterns can do for us is twofold. First, they provide a template to help us recognize common problems that can crop up in software development. With this knowledge, we can recognize an antipattern when we see one and identify the cause of it as well. The second part is that antipatterns provide a constructive solution to fix the underlying cause of the antipattern and to implement solutions that can be applied at several different layers in design. Let’s look at the first antipattern I discovered, the Blob.

The Blob is much like its namesake of horror film fame, the Blob. Here one single complex controller class is surrounded by many smaller data classes that merely encapsulate data. In this architecture process is separated from data, thus making this procedural style architecture. Some typical causes of the Blob are lack of object-oriented architecture or lack of any architecture whatsoever. A common occurrence of the Blob is from iterative development where code evolves from proof of concept to a prototype to a functional system. Another cause is a lack of architecture enforcement. But how can we fix this Blob problem?

Refactoring to the rescue! The first step is to locate sets of operations and attributes that directly relate to each other under a common goal. The next step is to locate natural homes from these groups and migrate them to their new homes. We then remove all redundant, indirect associations and migrate associates to derived classes to a common base class. Lastly, remove all transient associations, replacing them if appropriate with type specifiers to attributes and operations arguments.

This discovery of antipatterns for me was quite the find. I don’t know what but I still get a strange feeling when I hear antipatterns. It just sounds so menacing. The Blob was an interesting first antipattern to read as I’m positive that over my past coding projects, many of them would probably fall into this antipattern. It is nice to be aware of these potential issues now, rather than further down my career where it could have a greater impact if I ever do fall into the trap of an antipattern. I definitely plan to read more about these antipatterns and I plan to write about another one next week.

Until next time readers!

The Customer Wants What The Customer Wants

Hello, again my dear readers!

It appears that this week I am very focused on the customer this week as this article I read particularly focuses on what the customer wants. The article is titled, “Figuring Out What They Expected“. When it references they, the article is referencing the customer. The person you are programming the program or application for. Anyway, let us get into the meat of this article.

The article starts out defining two things. The first is what the user model is. The user model is effectively, what the user is expecting and thinking when they use the program. It bundles everything they know about computers and all their preconceived notions about using them when they sit down and use your program. How do I use this program and what does it do for me, the user? This is the model you are aiming to nail. If no one uses a program, does the program really exist? The answer is yes but we aren’t here to talk about that. The next model is the program model. This is what the programmer programmed into the program on how it looks, works, and operates. The idea in establishing this is that the user model and program model want to be overlapping or ideally mirroring each other. Now there are two ways to do this. The first is to change the user model. Good luck with that one. People are stubborn, stuck in their ways, and how would you even accomplish that anyway? Write a manual on how to use your program? We all know no one reads manuals anymore (although to be honest people really should) and if your program is different from what the user is used to, the user is likely to just not use your program. There is almost always another way. This leaves the program model changing to match the user model. I mean, let us face it, it might suck but you can change your program to match what the user will expect. It may be a pain but if it means your program is used more and ultimately bought more, I think it is worth biting the bullet.

The next part of the article goes over how to actually find that user model. The article has a simple and elegant solution… ask them. Then after you implement them, grab a few people and ask them to test them. Not a large group of people now. Only about 5 or 6 is required; after that, any more tests are fairly repetitive and not that useful. In the end, if the user has to guess how the program works, the program model is not quite there yet.

This article has reinforced my view that in this industry, the end user or customer is the ultimate determinant for a program or application. After all, we are programming an application for someone to use. If they can’t use it, its no good to them. I will admit, I’m surprised that only 5 or 6 people for usability testing are the norm. I do have a new appreciation for the Apple way of thinking where the simplest way to do something, is the way to do it.

Until next week readers!

Software Architecture Patterns: Building Better Software

Hello again, readers! Today I dove into an article by Peter Wayner detailing 5 different design architecture patterns for software design and their benefits and weaknesses.

The first is Layered architecture. This is where data enters the top layer and as it passes through each layer, the layer performs a specific task. A major benefit is that each layer is maintainable, testable, can easily be assigned roles, and are easy to update and enhance. However, this can result in the source code being very messy, the code can be slow, the whole program can be hard to understand, and changing a small part could be impossible as you may need to change the whole program.

The second is Event-driven architecture. A central unit is built that accepts all data and then delegates task to separate modules to ensure that your program isn’t just waiting around for something to happen. This allows for the program to be scalable, adaptable, and easily extendable. This can lead to complexity when testing and error handling can cause troubles in development. Essentially, the more each module is dependant on the others, the more troublesome the entire program becomes.

The third architecture is Microkernel architecture. This architecture uses a set of core operations that are repeated over and over again in different patterns depending on the data given. If needed, different modules can be tacked on to allow the program to perform different functions and patterns. The difficulty with this architecture is that getting the plug-ins and microkernels to cooperate can be tricky. There is also the trouble of not being able to modify the microkernel once plug-ins start to depend on the microkernel.

The fourth architecture is Microservices Architecture. The main idea here is to build a number of different tiny programs that will handle one specific task instead of having one big program do everything. This also allows some individual programs to be scalable up to a large size while others are kept small. Some downsides are that some tasks can’t be easily split up into a single microservice. Each microservice must also be independent or the cloud can become unbalanced. Lastly, if tasks are split up amongst several microservices, the communication costs can begin to skyrocket.

The final architecture is Space Based architecture. This architecture is designed to split up processing and storage between multiple servers. This protects against collapse under a great load. Data is stored across the nodes and information stored in RAM. This does make many simple tasks quicker but can also slow down computational tasks. This architecture can also be referred to as Cloud Architecture. The main drawback with this is that with RAM databases, transactional support is difficult. Testing the entire system can be difficult as well.

This was an interesting read as it went one step higher than what we learned in class so far. This covered the upper level where multiple programs come together while in class we cover designing a single program. The Space Base architecture was quite familiar as I learned about it in a Cloud Computing course I took earlier in the year that dealt with Hadoop. The Microkernel architecture was cool as well as I personally use Eclipse to work on in-class projects and learning more about its overall architecture is something I thought I would never dive into. The Event-Driven Architecture has given me an idea for a way to work on the final project that was recently assigned to us in class. Hopefully, it works out as putting something you learned to use is always a rewarding experience.

Until next time readers. Have a wonderful day and see you next week!

Keep Software Design Simple

Good day my dear reader! With it being quite deep in the semester now, one can correctly assume that I have learned quite a bit regarding Software Design and I have. With all this new information, I read an article that has helped me put all of it in perspective. This article was Simplicity in Software Design: KISS, YAGNI, and Occam’s Razor from the Effective Software Design blog.

This particular blog post is all about keeping your software design simple and details three different design principles to keep in mind while designing software and the effects of making a design too complex and conversely too simplistic.

The first principle is, “Keep it simple, stupid” more commonly known as KISS heralding that keeping designs simpler is a key to a successful design.

“The KISS principle states that most systems work best if they are kept simple rather than made complex; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided.”

The next principle is, “You Aren’t Gonna Need It” or YAGNI stating that functionality should be added only when it is actually needed and not before.

The last principle is Occam’s Razor, saying that when creating a design, we should avoid basing our designs in our own assumptions.

Not following these principles can result in complex designs that lead to feature creep, software bloat, and over-engineering. It could alternatively result in oversimplification where the design is too simplistic. This could lead to trouble down the line in areas such as maintainability, extensibility, and reusability.

Reading this blog post, made me sit back and think about my previous programming assignments. Looking back, my programs have been indeed, overly complex. A great quote provided in the blog post is from Brian Kernighan.

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

This gave me a good chuckle and is something I can definitely agree with and have done in the past. I will admit, that I had never considered the consequences of oversimplification. When the majority of your programs are single use for a specific scenario, you never really have to consider the consequences outside of getting the program done. An excellent quote provided by the author in the blog is from Albert Einstein.

“Keep it simple, as simple as possible, but not simpler.”

I completely agree with the author here that this quote expresses the danger of simplistic design that must be considered. It is easier to make things too simplistic rather than hitting the sweet spot of as simple as it needs to be.

This article will be one that I intend to keep in mind whenever I sit down to start a new programming project, especially as class projects start to roll up this time of the semester and I do believe that simple software design will greatly improve any designs that I come up with, keeping KISS, YAGNI, and Occam’s Razor in mind.