Apprenticeship Patterns Chapter 1

The first chapter of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye wasn’t really what I was expecting to be honest. Typically books for college classes are very factual and focus on learning new concepts, where they should be used, etc. This book, the first chapter at least, reads more like a career advice books. The authors are speaking from experience to try and provide insight and advice to people who are about to step into the field of software development (a.k.a. Computer Science seniors like us) or to those who are just getting started in it. I found the piece on Dave’s story to be particularly interesting. I always find it fascinating to see how people got to where they are in their careers, because the path taken is typically not what you would expect. In Dave’s case he got his foot in the door by essentially teaching himself Perl and proving to be he had what it took to be a programmer. He did that at age 26, so it wasn’t like he got a Computer Science degree, went right into the field, etc. It was an unusual path. He had to find another way to get his foot in the door. People who take the more difficult road often have the best advice, so I am particularly interested to see what he has to say throughout this book.

Now, more focus on what the purpose of this chapter was, which I feel was to provide an overview of what it takes and what it means to be a “software craftsman”. He goes on to provide a lengthy list of what “software craftsmanship” means, but I’ll point out a few that stood out to me:

  • “A willingness to experiment and be proven wrong” [AP] I feel this is very important. You simply won’t learn anything if you aren’t willing to try new things. This is applicable to all aspects of life, not just software development.
  • “A desire to be pragmatic rather than dogmatic” [AP] This is something I agree whole heartedly with. To have a program be absolutely perfect you will be working on it forever. Companies care far more about getting the job done in a timely and efficient manner than having it be perfect. If it gets the job done, they aren’t going to care how it got done in most cases.
  • “A need to always be adapting and changing based on the feedback you get from the world around you” [AP] Speaking from the experiences I’ve had at my software engineering internship, there are times where I’ll spend a week working on something and it will be scrapped because something changes late in the game. Or I’ll get halfway through writing a piece of code and realize there is a far better way to approach and I’ll have restart from scratch. You have to be willing to change and adapt to any situation at any point in time.

He then goes on to talk about three different stages of expertise in a craft: apprentice, journeyman, and master. I think it is safe to say most people taking CS448 are in the apprentice category. We all have so more to learn. Obviously, the goal is to eventually be a master at this craft, and hopefully this book along with the “apprenticeship patterns” it discusses will help get one step close to obtaining that goal.


Link to book:




Java Testing Tips

Since I would consider myself a novice with Junit and java testing, I decided to take it upon myself to try a learn a bit more about it since we have been using it in class. I found a blog on by David Salter that discusses a few tips on this topic, which I found to be quite insightful, so I am hoping to relay those tips to you.

The first tip is to follow the AAA pattern when writing tests. That is Arrange, Act, Assert. Arrange the conditions at the start of the method, act on the system, and then assert that the results are what you expected them to be. I am always a fan of easy ways to remember things, so I really like this acronym. It a nice easy way to remember what a good java code test should include.

To go along with the AAA, there is an important thing to remember when using the last of the A’s, assert. Although assert is a cool and powerful feature, you must be careful as to where and how often you use them. One should be careful that they are not testing things that the method wasn’t intended to test. It is also important to make sure you are not testing too many things in one method. This cause headaches if a tests fails, because it requires debugging multiple methods/classes, rather than being able to focus on just one. This tip really stood out to me because I think one can easily go down this rabbit hole thinking that they are making their lives easier, while in reality they are making it harder.

The last item I want to discuss is important to testing, but it is also important with regular development as well. Take advantage of what the software has to offer you. It can make your life a lot easier in the long run if you take the time to learn a new feature or two. Although you have to invest time upfront learning how it works, you can save a lot of time because that feature makes it easier for you to develop, debug, etc. For example, libraries like EasyMock and JMockit allow you use a mock object. This allows you to “mock” objects that do not exist yet. The example used in the blog us mocking a security system that controls who can access what, depending on the user logged in. Because you are able to create a mock one, you are still able to test your product, even though a key component is missing.

Obviously there a lot of different tips a whatnot to help make us better testers. This really is just the tip of the iceberg, but I hope it was as useful to you as it was to me.



Some Traits of Smelly Designs

In the past, I have talked about Code Smells. However, did you know there is also a Design Smells theory? What’s the difference? Well, according to the CodeOps blog, “Design smells are certain structures in the design that indicate violation of fundamental design principles and negatively impact design quality.”. In other words, the difference between code and design smells is Design Smells focus on the design quality and principals (the architecture of the code) while Code Smells focuses on poor coding practices (what bring the architecture to life). The blog mentions a couple of red flags to look out for the may be an indication of Design Smells that I feel are worthy of discussing. Since I know I have perhaps accidentally or perhaps out of laziness have done some of the thing mentioned in this blog, I figure it can a good learning experience for both myself and the readers of this blog.

Violation of design principals: They use the java calendar class as an example. Not only does it support dates, but it also supports time. Since it has multiple roles, it is in clear violation of the Single Responsibly Principle (the first of the SOLID principals discussed a few weeks back). This is known as Multifaceted Abstraction smell. When you think about it, violating design principals is clearly a bad idea. The principals are there to promote better design and coding, so going directly against is clearly not the brightest idea.

Inappropriate use of design patterns: This one is on the opposite end of the spectrum. Instead of complete ignoring common practices to promote better code, you force it upon yourself. Just because the design pattern could be used in whatever situation you might be in, it doesn’t mean that it should be. Don’t feel obligated to use them if you feel if it will do more harm than good.

Language Limitations: Sometimes languages force you to do thing you don’t want to do, and often times it can be out of your control. Java is used as an example again. Because java does not support primitive types, if you need to take in different primitive types, you will need repeat the code, with the type taken in being the only difference. While I agree that language limitations can promote bad practices, I don’t know if it is fair to considered this to be a trait of a smelly design since unless you were able to pick the language, there is largely nothing that can be done about it.

Viscosity: This is basically taking the easy way out. Sometimes there is a hacky way to solve a problem that may be prone to errors, isn’t modular, etc., but it saves significant time and resources. Because developers are often under a time crunch, they often resort to this. I know I have, but I also know it will come back to bite you. Avoid the hack if possible.

Obviously, there are various other causes of smelly designs, but I hope this short list gave you a good idea of what Design Smells is all about.


Unit Testing Tips and Tricks

First of all, what are unit tests and why are they important? The meaning behind them is kind of given away in the name. They are designed to test individual features/components (a.k.a. units) of code to makes sure it is working the way it is supposed to. This helps eliminate external factors like other features affecting the one you want to test. Unit tests are used anywhere and everywhere whether you are aware that you are using them or not. I can say that we use them on a regular basis at work and I use them when writing any sort of software, even if I might not specifically think “Lets unit test this piece”. With unit testing being so important, I thought why not see if there are ways to improve them, and luckily Stormpath has a blog with tips on it that I found quite useful and intend to use in the future.

The first thing they suggest is to use a framework for testing such as Junit. To put it simply, these frameworks just make life easier. They help setup, organize, and run your tests and I cannot agree more that frameworks both make tests easier and help improve testing. Next on their list is to use test driven development. This basically means that your write the tests before you write the code. Assuming the tests are written based off requirement, this forces you to make sure you hit those requirements and it provides a more complete, modular product in the end. I generally agree with these, but I do believe there are times where this can be difficult. Sometimes the customer may not know what they want to end product to be. What happens if the design shifts in the middle of development? Then you might have to rewrite all of the tests. If possible however, test driven development is a good approach to use. They then suggest to check how much code you are covering. In other words, are you testing every line of the unit you are testing? If not, you are leaving yourself open to bugs. Stormpath discussed a couple of other suggestions as well, but they have one that I feel is particularly important, so I am going to devote my time to that one, which is to tests negative situations and edge cases.  Sure, you’ve tested all of your code and it works as long valid data has been entered. However, your program doesn’t live under a rock, so it is going to be exposed all sorts of situations. This can include users putting in invalid data. You have no control over what they are going to do with it, so your program needs to be able to handle those situations. I would argue that testing edge and invalid tests cases might be more important than normal test cases, simply because you can probably predict how it will be have when the user stays in bounds, but who knows what could happen if they don’t.



DRY, KISS, and YAGNI Design Principals

This week I have decided to continue with the discussion about design principals from last week. I like design principals because they generally provide important things to keep in mind while coding and are written in a fashion that is easy to remember (typically an acronym of some sort), which is why I’ve continued to discuss them. This week there are three I want to discuss: KISS, YANGI, and DRY. Now, you might be asking, why three? Well, these principals all focus on keeping things as simple as possible, so they kind of go together. Jonathan San Miguel has nice blog that discusses the basics of these principals.

First in the queue is DRY. Don’t Repeat Yourself. Another way of putting this would be to say, “don’t reinvent the wheel”. Have you ever been looking through your code or someone else’s code and realizes that there are similar or identical pieces of code in different parts of the program? Well, following this design principal will help eliminate that. You shouldn’t have to repeat code, and if you do, the original piece should be redesigned so you don’t have to waist your time writing the same thing over and over again. I always find it frustrating when I find similar code because I have to spend time trying to determine if they are exactly the same, why there is a need to have it twice, what is the little variation in it that made them write it twice, etc. So to summarize, unless you have a clear, distinct reason for repeating code, don’t do it.

Next up is KISS. Keep It Simple Stupid. This one is kind of self-explanatory, but basically it means don’t make your code more complicated than it needs to be. Keeping code simpler makes it easier for others to read, easier to modify, and easier to look back to later on. I especially agree with being able to go back and modify later on. At the time, the complicated code you wrote probably made perfect sense to you, but if you go back to it a year later to make some adjusts you may end up asking yourself what the heck you were trying to do with that piece of code for the next two hours. I know I’ve done it. Miguel also suggest avoiding using language specific features. By avoiding this, it can allow other people that aren’t familiar with the language to still understand what is going on.

Last on the list YAGNI. You Aren’t Gonna Need It. If you don’t need a feature at the point in time of writing it, don’t include it. You don’t need it now and you probably won’t need it in the future. You are simple wasting your time and other people’s time as well as probably causing some confusion.

I hope you found these principals insightful and useful. I know I did and will keep them in mind when writing code.



What Is Needed to Make Automated Testing Successful? Some Basics…

Testing software can take up a lost of time. One way to reduce the time spent on testing is to automate it, meaning that a person doesn’t have to run each individual test manually. Automated testing is the way of the future, and there is information everywhere on it. Bas Dijkstra of discusses some of the basic principals of automated testing in his blog post, “5 Pillars of a Successful Test Automation Implementation”.

The first of the five pillars is the automation tool. Everybody has to have some sort of tool to help organize and run automated tests. Testing teams often overlook the tool and just go with whatever is available on hand. By doing this, they may be making their own lives more challenging. Take the time to make sure you have tool that fits your needs. I agree that this is an important first step. If you pick or are forced to use a tool that is poorly designed or doesn’t meet your needs, you are putting yourself behind the eight ball to start.

The second and third pillars discusses test data and test environments. Depending on how broad the scope of the tests are that are being run, data can become a pain to maintain. You want to make sure that you have this situation under control or you are asking for trouble. It is easy to imagine how out of hand and disorganized this could get in large scale testing. To go along with test data is the test environment. Have an environment that is as realistic as possible. Make sure it has everything you need to complete your testing and if possible, make it easy to replicate. This can allow you to run multiple tests is independent environments and/or continue with develop in one of the environments. Nothing is more frustrating that not having an environment to do you work on, whether another team member is using it, it is down for maintenance, etc. and one that is easy to duplicate can help eliminate this problem.

Next is reporting and craftsmanship. Reporting is vital as it allows others and yourself to analyze test results. Dijkstra suggests that a good report should show what went wrong, where it went wrong, and the error message that went with it. This can relate directly to craftsmanship as testing can be challenging if the correct skills aren’t available. There should be someone who has experience creating reports, for example. Make sure the correct developers, engineers, etc. are on hand to answers questions and help when needed.

My experience with automating testing is limited, which is why I have started to investigating it. From experience with manual testing, I can say that what Dijkstra discusses certainly applies, so I see no reason why it wouldn’t apply to automated testing too. I hope continue reading about automated testing as I feel it is an important and necessary tool/skill to have.



S.O.L.I.D. Design Principals – What Are They and What Purpose Do They Serve?

This week I went back to Professor Wurst’s concept map looking for some fresh material to research. This week’s topic of choice are the S.O.L.I.D. deign principals. These are design principals discussed and promoted by Uncle Bob (Robert C. Martin). The goal of having design principals is the make software easier to deal with, maintain, and expand upon. Samuel Oloruntoba does a great job at giving a general overview of these principles in his blog.

First things first – what does S.O.L.I.D. stand for? Well, it stands for Single-responsibility principal, Open-closed principal, Lisko substitution principle, Interface segregation principle, and Dependency inversion principle.

Single-Responsibility Principle: A class should only have one responsibility. In other words, a class should perform only one job. This can be applied to help make your program more modular. If you have a class that performs many tasks, it can become challenging to make changes to it.

Open-Closed Principle: It should be easy to extend a class without having to make changes within the class that needs to be extended. In other words, be prepared for the future. Don’t assume that the class/program will ever need to do additional things/serve a different purpose than it does today.

Liskov Substitution Principle:  Every subclass should be able to act as a substitute for the parent class. This once again promotes the ability to extend upon a program if need be.

Interface Segregation Principle: Don’t make people use methods or interfaces that they don’t need to use and/or are not needed. In my opinion, this can create unneeded work for the user and can cause confusion/be deceptive because it may not be clear what they need to do.

Dependency Inversion Principle: Items should depend on abstractions rather than concretions. Don’t pigeon hole yourself. This is probably best explained in an example: Say you have class LandscapeWorker with several methods including one that assigns a piece of equipment to them. Once could simple assign the equipment in the LandscapeWorker class, but then if they want to switch equipment, you would have to change the LandscapeWorker class that should not have to be changed. Instead, have an interface called equipment with separate classes for each piece of equipment, that way the class can simple be called.

I feel design principals are important as they help paint a picture of the logic and power behind programming languages they are designed to be used in. They cause you to think of new and better way to design code in ways you may not have beforehand. This is why I chose to discuss some of them this week. I feel that S.O.L.I.D. design principles are a good place to start for anyone, including those who are just starting out. I understand that I have barely scratched the surface with design principals in general and purpose behind the ones discussed here.  In the coming weeks, I hope to dive deeper into design principals and perhaps go in-depth into some of the principles discussed here. Stay tuned.



Bug Taxonomy – Classifying Software Bugs

This week I have decided to change things up a bit. Seeing as we are now past the halfway point in the semester, I decided to start exploring some blogs other than the group I normally browse, just to try and find a different voice, a different point of view. I am happy to report I have succeeded in this mission, and have found a blog post by Michael Stahl on that clicked with me.

One of the recurring problems we face as testers is making sure that we have covered everything that could possible happen in a piece of software, good or bad. Stahl suggests using bug taxonomy as a way to think of new ideas on what needs to be covered. This type of taxonomy is not trying to compare types of testing with type of bugs, but trying to put software bugs into categories. If you have a list of categories you can go to each time you run through the testing gauntlet, it may allow you to think of new tests that need to be written for your product. A few bug items under the category of performance he suggests are from Testing Computer Software, by Cem Kaner, Hung Q. Nguyen, and Jack Falk: slow program, poor, responsiveness, and no progress reports. His list goes on, but you get the point.

Once I saw this list of categories, this strategy totally made sense to me. Basically, have a list that is entitled “Have I covered:” or something to that extent. Running through the list forces you to think of scenarios you may not have covered, but should be covered. And since the list is categorized (i.e. performance, user experience, etc.) it allows you to focus on one testing area at a time. I can tell you that after reading this post I made a list of things I need to go back and check on for something I am working on at work. So, this strategy has already paid dividends for me.

Although other testers list can be useful and is a good way to share ideas, Stahl strongly suggests making your own list to reference again and again. This is because you may not agree with how another person’s list is laid out. For example, in the list from Testing Computer Software, Stahl mention how under the performance category is “no progress reports”. He feels it should be under a user experience category. I agree that is should be under user experience, but these lists are all up to the testers opinion, so it is not wrong that the book has it in a different spot. This can be avoided by making your list.  

I really enjoyed this blog because making a bug taxonomy list seems like a relatively simple way of trying to find new tests. It practical, and be applied in everyday use without a big hit on time. We always talk about how important time is with testing, so if there is a quick and efficient way that is going to help make my tests better, I am in.


Link to picture:



What is Smelly Code and Why Your Code May be Stinking Up the Room -Continued…

So, we meet again with what makes code stink. As I mentioned in my blog last week, this is a continuation from the same post that I covered last week, as there were simply too many points I wanted to hit upon to fit in one post. For those who missed last week’s post or can’t remember, smelly code is basically trends in code that commonly known to cause problems. The goal is to make sure you code doesn’t stink when you are done with it, or you’ll regret it later down the line.

The next item on the list are comments. Comments can be great. They provide insight into how the developer was thinking, why they designed it the way they did, what is going on in that quadruple nested for-loop below the comment, etc. The thing is, if you are really a good developer, an argument can be made that the code can speak/explain itself. Personally, I’ve always found comments useful and insightful, but the point here is that your code should not be so ambiguous or so complicated that you need an entire paragraph just to explain what is going on. While I don’t necessary agree that there should be no comments at all, I do agree that comments should be kept to a minimum, and if you can’t, something is wrong with your code.

Pressing further down Jeff Atwood’s list of smelly code we run into the category of duplicate code. Please don’t duplicate your code. The reasons are self-explanatory, but I will reiterate: it is bad, wasteful, and inefficient. If you need to perform a task more than once, put it in a function, simple as that. You’ll save everyone a few headaches. Similarly, he mentions dead code. That is code that is sitting in there, wasting its life away as a comment or performing some task is never used, wasting resources. There should never be a need to leave unused code. The wonderful invention of version eliminated the need to leave old code sitting in a program.

The last item on his list that I want to touch upon is the bad habit of making items public when shouldn’t be, or as he calls it, indecent exposure. There should be a strong effort to make everything is as private as possible, and there should be a damn good reason if it not private. Exposing the internals of a class is dangerous and unwarranted. Unless something absolutely has to be public, it should stay private.

There were items on Atwood’s list that I felt were unnecessary or didn’t completely agree with, but overall, I found his list of code warning signs useful and brought up many valid points. As developers we want our code to be clean, efficient, and easy to read. I feel that going through this list would certainly help anyone reach that goal. A lot of the items on the list are thing experienced developers should know better than to try anyhow, but it can’t hurt double check when you are done. I know I certainly will try to run through his list in the future.