The Importance of Names

I’ve heard a lot of great things about “Clean Code” by Robert “Uncle Bob” Martin, and when I saw that the Coding Blocks Podcast had done a small series reflecting on the material of the book, I jumped right in.

Clean Code (although I haven’t read it yet) is a book that aims to set a standard in software craftsmanship, so that code isn’t lost as a result of being difficult to reuse, refactor, or even… well, read. The podcast reflected on Chapter 2 of the book, Meaningful Names. Allen Underwood and Michael Outlaw discussed major points that the chapter touched on and their personal experiences with each.

The segment that may have had the most impact on my outlook towards this subject was one of the first ones in the podcast — that the names of variables and methods should be as descriptive as possible, so that you don’t necessarily need to write a comment that explains what it does. This seems self explanatory, but I’ve already caught myself feeling compelled to comment every variable I declare in order to explain the differences between nondescript declarations like numDays and dayNum. Even if it’s just a small personal project, getting in the habit of writing effective variable names is a practice to start sooner rather than later.

They made another great point later on during the show too — Don’t be afraid of long variable/method names! So far in my educational experience, I don’t think I’ve needed to bother with a program that was more than ~500 lines total. In this case, it’s pretty easy to scroll to find what you’re looking for in each class. However when you’re dealing with a full software program, having a variable name that is easily searchable can save an enormous amount of time.

Certain topics touched on, like the “Hungarian Method” for example, I was completely unfamiliar with. I think standards like that may have been more niche or were perhaps prevalent before my time writing code. I agreed with what they said about it in the podcast, and I think the idea of a common naming convention is a good one however having code that is clear and easily readable is a better alternative.

This series of podcasts were really good, so I’ll likely be writing about it a lot more in the near future. There was a whole lot more that they went over, and it definitely made me interested in reading this book.

Here‘s a link to the episode on their website, check it out!

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Blog 2 CS 443

My blog this week is based upon this article in which the author explores “shift left testing” which is simply a fancy way of testing earliest in the production of a program as possible. In this article the author goes into detail about several different forms of shift left testing, all of which try to push the testing earlier into the development of a program. The author also reviews why the common practice of testing late in production phase has been a major harm to system and software testing.

I found it interesting that the testing phase is often left so late in the development, with some major consequences pointed out by the author. One of these consequences the author highlights about this method is that it often results in “wasted time”. This can happen because “Many requirements, architecture, and design defects are not uncovered and fixed until after significant effort has been wasted on their implementation.” This article also focuses on what I feel is a much better approach to the development in which each part of the original “V-model” of production is broken into separate “V-models”. This means that for every part of the production phase, whether it be design, coding, fabrication, it is accompanied by a testing phase. This does require more time in the production but will ultimately produce a better program with fewer to no faults. I believe employing this strategy in one’s own personal work would be a very smart idea. This can be done for example while creating a program yourself, with every part of the program you write, you test it to make sure it is correct. This will help by the end of the program when you could generally have several mistakes causing errors throughout the program. One final thing the author points out which I believe could be relevant to those not employing this method is that late testing can lead to missed deadlines, whether it be for a company or for a student working on a project.

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

Blog 2 CS 343

My blog this week is based on this article which talks about the author philosophy behind debugging and how people often fail to debug properly. One of the first things the author talks about is how it is important to once presented with a program to debug, the best thing to do is know and admit that you do not know the answer immediately to whatever problem there is. He says this to follow up with the importance of gathering the information about the problem that will help much more then just simply trying to “guess” a solution. One other important point that the author made in this article is that most programmers tend to try to find a “bandage” for the bug they are presented with. The author believes if someone debugs a program properly “you’ve actually caused some part of the system to go away, become simpler, have better design, etc. as part of your fix”.
I personally found the authors advice of trying to understand the problem further before even attempting to create a fix to be very helpful. Looking at how I’ve done things in the past I know that I would often simply try different things to come to a fix for a problem. One way the author suggests to help fix this is to gather data about the bug until you fully understand the cause of the bug in the first place. You can do this by trying to recreate the bug for yourself to see the cause of the issue, or try referring to the way a proper program should behave. Another point I took away from this article was that when you are debugging something you should be eliminating code to make the program simpler and better in design. Often times you can think the proper way to fix a problem is to add something to the code to handle whatever problem is occurring, when you should rather be making the code simpler to begin with. I feel this is a very smart way to code/debug because anytime you can make the code of a program simpler, yet act in the same way, is good for both other programmers to look at in the future and for the users of the program itself.

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

The Benefits of Unit Testing

This article by Ekaterina Novoseltseva on DZone (DevOps Zone) is about 8 benefits of unit testing. In the article, she breaks down how her company, Apiumhub, utilizes unit testing in order to stay Agile. She also breaks down several of the benefits of unit testing including relation to Agile, quality of code improvements, reduction of costs, and several others.

I found this article interesting because while I knew some of these benefits of unit testing, I never thought of some of the specific examples like the relation to Agile. She points out that unit testing facilitates “safe refactoring” by forcing developers to use the smallest functionality possible for testing a single unit. I agree completely with her in regards to Agile especially after she pointed out that this goes hand in hand with extreme programming and test driven development.

Personally, I’d never used test driven development at a large scale before so I’ve never really considered the benefits. The section on the benefits to design really pushes the idea that test driven development makes code more optimized, with cleaner designs. When breaking everything down into a unit first, figuring out what each unit is, and defining what the functionality is through tests, you are forced to consider the designs of the actual functions before writing them.

Another point that she makes that is probably one of the most important to the business is that unit testing reduces costs for the development process. Unit testing finds bugs early in the process because the tests are either written before the code is even written, or before moving onto the next snippet of functionality in order to stay Agile. This means that application-breaking bugs are less likely to be found in the later stages of the development process like “system testing” or “acceptance testing” as Ekaterina points out in the article.

I wholeheartedly recommend this article to anyone who is relatively new to unit testing and doesn’t is any bit unsure of the possible reasons why unit testing is so important. I can see myself utilizing unit testing more in my personal projects in the future as I already try to work on them in some resemblance of an Agile process.

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

A Review of Software Engineering Radio’s Conversation with eBay’s Randy Schoup (ep. 109)

I was interested in what someone from such a large website, eBay, would have to say about its architecture. There was a lot of takeaways from it, summarized in four main ideas: partition everything, use asynchrony everywhere, automate everything, and design the system keeping in mind that everything fails at some pint in a large distributed system. Although this is an older talk (from 2007), these all seem to be sound systems to design something so large. He referenced a theorem from 1998 that he said took a while to get traction. Likewise, I am sure his design principles have proven true for the last ten years.

To be completely honest, there was a lot of industry-specific jargon used that went above my head. I took a lot of notes though, and looked up the terms I did not know. I still found it very interesting, though. I found it the most interesting that someone designing one of the largest websites in the world was incredibility realistic of the shortcomings of everything designed. It seemed that everything designed had to have a degree of compromise of what was expected of it. He referenced the “CAP Theorem,” where it seemed you cannot always have all three parts that it stood for — “Consistency,” “Availability,” and “Partition tolerance.” He also was realistic that everything can fail, especially  when the system gets as big as it gets bigger. For some reason it surprised me when someone from such a prominent company would admit this.

Something else that really surprised me what he said one of their biggest limiting factor was something I would not have expected, which was power consumption. He claimed that some companies’ database centers can use more energy than a local power station can support. This makes it much more important to design efficient database structures, especially in a company that deals with data in several petabytes.

It just boggles my mind how reliable websites like this are for millions upon millions of consumers. He said $2,000 worth of transactions were made every second, and that was over ten years ago. The site has grown since then. This gave me some great ideas to run with, as I hope to one day work for a company as esteemed as his.

Link: http://www.se-radio.net/2008/09/episode-109-ebays-architecture-principles-with-randy-shoup/

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

The Development Abstraction Layer

This week I read a post of Joel Spolsky, the CEO of Stack Overflow. This post talks about the development abstraction layer that software developers work and are responsible for in a software business. The author started with the story of an experienced software developer who left a big software company to start his own business. He was confident that he could develop and sell software by himself because a lot of software products he worked on for the big company were sold pretty well to many customers. However, after months he could not get order from customer to support his own business and living cost. Finally, he had to come back to work for the previous company. He wondered why he failed with his own business. He was pretty sure that he lacked good marketing for his business. Marketing simply stands for everything in business of creating and selling software that he and many developers don’t understand all about. He was wrong. Software is a conversation, between the software developer and the user. However, that conversation requires a lot of work beyond the function of software development. It takes marketing, yes, but also sales, and public relations, and an office, and a network, and infrastructure, and air conditioning in the office, and customer service, and accounting, and a bunch of other support tasks.

Software developers design and write code, layout screens, debug, integrate, and they check things into the source code control repository. The level that a developer works at is called the development abstract layer, which is too abstract to support a business. The development abstraction layer needs an implementation layer — an organization with many support tasks – that takes their code and turns it into products to customers. The top priority of a software team manager is building the development abstraction layer that all developers only concentrate on and they don’t have to concern about other tasks.

The post gives us an idea of the scope of work that a typical software developer works for. A successful software company should have good support tasks across the board to help developers do their best and turn their works into quality products to customers. Moreover, if we plan to start a software business, we should understand which tasks we need beyond the development abstraction layer to keep our business running well.

Article: https://www.joelonsoftware.com/2006/04/11/the-development-abstraction-layer-2/

From the blog CS@Worcester – ThanhTruong by ttruong9 and used with permission of the author. All other rights reserved by the author.

Rapid Software Testing

The podcast that I listened to for this week is from a podcast called Test Talks by Joe Colantonio. In this podcast he has Michael Bolton as a guest, who is a software tester and testing teacher. He helps solve testing problems for people who did not realize they could solve them. He is also the co-author of Rapid Software Testing along with James Bach. Rapid Software Testing (RST) is “a methodology and mindset for testing software expertly and credibly in uncertain conditions and under extreme time pressure”. The first thing the two discuss is the three main points of RST. That is skill set, mind set, and its class. Some of the main things that they focus on when it comes to RST is finding trouble with it, they like to explores the risks of it, what bugs will threaten the value of testing, or the project or the business. Michael also emphasizes the importance of testers being able to express clearly what they are here for, quickly and to the point. Another topic that they then speak about is the nonexistence of manual testing, which he talks more in depth about in his own article on Developingsense. He talks about how manual testing does not exist. Testers need and use tools and they engage with the product.
There were a lot of things that I really liked about this podcast. The first thing is that I never knew who Michael Bolton was, and that he was the co-author of something like RST with James Bach. I also really appreciate what he had to say about manual and automated testing and how they exist and why it had ever existed in the past. I also really liked how he mentioned that when people think too much about what they should be including, the bureaucracy, they forget about creating the actual product and what they want to do. They forget about looking into the problems. People do not spend their time wisely when is come to various aspects of the product. People are not taking an appropriate level of time to review and check their own work. More excessive structure and documentation which displaces the time we actually have to do our work is the biggest problem. A lot of what he had to say was very true and I think that the time does not get taken into account with coding and testing for projects. Overall I really liked the podcast and felt it was different from the usual informational podcasts that are geared more towards how to test and the different kinds of testing and instead on what will make you a better tester.

From the blog mrogers4836 by mrogers4836 and used with permission of the author. All other rights reserved by the author.

Thanks for Coming to My Test Talk™

CS SERIES (3)After learning some life lessons through the pages I’ve skimmed from my copy of The 7 Habits of Highly Effective People by Stephen Covey; this article’s version for software developers in test caught my eye. What exactly are the seven highly effective habits of SDETs? Here are the seven habits that Angie Jones, a senior developer advocate at Applitools, wrote about: being intentional, enhancing development skills, enhancing testing skills, exploring new tools, automating throughout the product’s tech stack, collaborating, and automating beyond the tests.

If anyone is interested in becoming a SDET, they should follow Jones’ advice as she is very familiar with interviewing SDET candidates. Something thought-provoking about the first one is how automation projects are not always the best option. Before this article, I understood that not everything required automation but it was the end goal for more projects or companies overall. This is due to my experience; for some reason I believed that just because the company I was at wanted automation for something that everyone else would too. After reading this, I am now understanding that automation is only the goal when it is aligned with the overall outcome.

I am noticing a consistent pattern of guides to becoming a good software developer or tester containing similar tips like “enhancing development skills” and “enhancing testing skills” as people in this industry must always keep learning to stay on top of what’s new. Due to the repetition, I have been trying to keep an eye out for the more unique ideas. One of the ideas that stood out to me more is the one of collaborating.

Jones listed careers ranging from business analytics to software development and mentioned how they would be good matches for pairing up with SDETs to help each other better understand certain features and the importance of what they will be working on. From a sociological standpoint, I like this approach to finding all the resources to complete a project outside of the department. As someone who is always looking for ways to connect with people or connect people to other people, this is an effective idea for helping companies and their people feel more at ease with their jobs. The SDETs may feel less pressure knowing they are not entirely on their own and can request help when necessary.

Article: https://techbeacon.com/7-habits-highly-effective-sdets

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Value of Unit Testing

When you ask a group of developers what is more important, writing adaptable code or writing tests for the code to pass? I believe that both are equally as important as the other. I came across a blog by Tobias Goeschel, “Writing better tests with JUnit”, where he talks about the importance of writing better tests. In order to keep your code as high quality as possible, you must write tests. Poorly written tests as he describes may lead to bugs bypassing your code and having malfunctions in your program. As he lists in his blog, a set of well written tests will tell you (and more):

  • How to access the API
  • What data is supposed to go in/out
  • What possible variations of an expected behavior exist
  • The exceptions that might occur
  • How parts of the system interact with others

Tobias goes on and talks about how good tests should not be underestimated because it not only helps new team members understand what should be done but also reviewing old code that’s to be tampered with.

Reading through this article it all makes sense why we were always so test driven with the projects that we did in Data Structures. Every project we wrote had to pass a certain amount of pre-written tests. The author stressed the importance of unit testing which changes the way I will write in the future. Not only will I focus on written code but also tests. I believe that Unit Testing is equally important as mentioned.

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

B2: Static vs. Dynamic Testing

https://www.360logica.com/blog/difference-between-static-testing-and-dynamic-testing/

            While trying to gain more information on Static and Dynamic Testing, I found an interesting blog post that pit the two against each other. It started by explaining that Static Testing is used to test things related to the actual code within a product. The post further says that Static testing is where developers check code to find faults. This testing can be completed without any current applications. The post then defines Dynamic Testing as testing the application with valid entries and checking their outcomes against an expected result. After explaining the two terms, it stated the major differences between them like how Static testing is a preventative measure while dynamic testing is used in solutions. The post explains that Static testing is therefore more cost-effective and provide greater benefits when compared to Dynamic testing. Dynamic testing can take longer as it tests each case separately while Static testing can cover more in a shorter amount of time. The blog post goes on to explain that since Static testing is done in a verification stage, the code can be looked at without any execution. This differs from the Dynamic testing which is done in a validation stage where the code is executed and tested without being looked at.

            I chose this article because I found myself interested in the difference between Static and Dynamic Testing. I understood these terms in a programming sense, but I didn’t quite grasp the concept in a testing setting. My initial curiosity was filled with a sense of what these different testing types meant. I found the post very informative on what each testing type did and how they worked. I can understand that Static testing is better overall because of its speed and benefits but I also understood how Dynamic testing works as well. I enjoyed how the post used multiple examples when explaining these terms because it allowed me to get a better understanding as to the context of the definition. This blog post has taught me that Static testing is the go to style for testing as it is cost-effective and overall better. The most interesting part about this post was the different benefits it stated between Static and Dynamic testing as it gave a better insight to how they both worked.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.