https://blog.codeship.com/behavior-driven-development/

          This week, I found a blog post that talked about Behavior-Driven Development and explains how to implement it within Computer Science. The post begins by defining behavior as the way the user wants the application to behave. It explains that you must have a clear idea on the user needs for this implementation to be successful. The implementation of this is done by dividing the user needs into small stories which have selected keywords to help define the behaviors of the application. The post uses examples very well to explain these ideas by highlighting and explaining important phrases. The selected keywords are used to put the stories into a more “readable” format while also creating behaviors based on the user needs. The post gives some advice after this, saying that the most important behavior to the user is the best starting point for these stories. Then you just keep building off that idea to encompass a final product that you can show to a client to make sure that all needed scenarios are covered.

            I chose this article because I was curious as to what Behavior-Driven Development entailed within the computer science world. I had no idea what this term was before reading this article, but I have gained a much better understanding now. I found this content enlightening in the sense that it taught me to think a bit differently. I enjoyed how the post explained the importance and implementation of this development through the use of these stories. I found this way of understanding user needs very helpful and a fresh new perspective compared to other things I’ve tried. I was able to understand how the development process works by starting at the user needs first. This will affect my development process by allowing me the option of working with the user to create better specifications. The most interesting part of this blog was the overall explanations for the development process. It was intriguing and informative while teaching the purpose of properly addressing the clients by starting with their needs first. I found this subject very interesting and this source was a good resource to understand with its use of examples and visuals.

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

What is Behavior-Driven Development you ask? To know that you must know what Test-Driven Development (TDD for short) is first. Keeping it short, TDD is a software development methodology that states for each unit of software, the developer must:

• Add a test
• Run all tests, see if one fails
• Write code
• Run test to implement code again
• Refactor code to past test
• Repeat

Knowing what TDD is, Behavior-Driven Development is merely an extension of TDD that makes more specific choices; meaning it focuses on specifying behavior and how the user wants the application to behave.

In Clemens Helm’s blog about Behavior Driven Development, he talks about the initial steps of BDD which starts off with the piece of functionality that is most important to the user; in other words we should develop software by centering our users. The purpose of this is so that developers know where to start and are on the same page in the development process of the project.

Some advantages I see from BDD is that it helps shift the focus to the expected end result and functionality of the program between the developers, QA, project managers, and business team. I found this particularly interesting because I always thought that communication was the utmost important part when it comes to creating anything as a team but I guess in a real work environment that is not always the case. I see that is what we’re learning to do in our Software Quality Assurance and Testing class; working as a team with different roles and I believe this is a very good skill to develop. I think that I will most likely try to incorporate this in the way I work with others in the near future.

Share your thoughts in the comments below!

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.

Today I read an article titled “Software Development Trends in 2018 That Will Dominate in 2019” This was a very interesting article that talks about the current trends involved in software development and how they will continue to be a force to be reckoned with in 2019. The article talks about 5 different trends that will be huge in 2019: Artificial Intelligence (AI), Progressive Web Apps, Blockchain Technology, Cybersecurity, and Low-code Development.

I chose to write about this article because I already knew that AI is one of the biggest current trends in software development, but I thought it would be interesting to read up on other trends in the world of software development. This article did not disappoint as I was able to learn more about Blockchain technology. I personally never heard of that before reading this article. I read that it was being used in the medical field, and it was being applied to the medical data in order to store it safely within a network. This appealed to me because my sister, and mother both work in the medical field, and I am sure that this could be useful in their line of work.

Although, I knew that AI was going to continue to be a huge trend in Software Development, I learned that AI will be used by “more than 40% of the organizations to automate their business in 2019” (Williams).

This article didn’t elaborate on low-code development too much unfortunately, but basically, it allows developers to build software without much expertise in coding. This part actually brings up an intriguing thought. While it does help people without expertise code more, could this be a bad thing for other developers? If everyone is given the opportunity to easily learn code, will that possibly take away opportunities from the extremely hard working developers? I don’t believe that will actually happen because the software development field is constantly evolving, so those with expertise in the field will continue to thrive.

Cybersecurity was the last trend that will continue into 2019, and I do feel like this is a given. The article mentions that 18% of companies did report at least one security incident in 2018. This is still an alarming number because some companies have a lot of important information that shouldn’t be leaked or taken. The trend that will continue is that these companies will look for Cybersecurity developers and thus, better programs will constantly be developed to virtually guarantee complete protection for any company’s data.

Article: https://medium.com/@Jessicawlm/software-development-trends-in-2018-that-will-dominate-2019-db1a1681c84d

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

So for this week, I have decided to read about “Pros and Cons of Dynamic Testing and Static Testing” from the testbytes blog. The reason I have chosen to read this blog is because I only have heard bits of both testing methods and I want to understand the advantages behind them. This will help me in seeing how they work and be able to use them in an expected way.

This blog post basically goes over as the title says the differences between static and dynamic testing. Both have their own purposes in making sure the software runs functionally. The blog post provides the techniques used and what are the benefits overall in both testing.  Static testing is an early stage of development and can be done manually or with a set of tools. It is useful in seeing the code flaws and giving documents to review the overall software. Another name for this test is verification testing.  With dynamic testing, the code is used to check how well it will perform in a run-time environment. It is to ensure that the end product is designed with the requirements given by the business clients. Another name for this test is execution testing. This one can be used in any levels of development. With both of these methods by their meanings, development companies can use them in to design flawless products in concept.

What I think is useful about this content is the way the ordering goes. From the blog, the definition is explained first to get the basic idea of the testing, then the techniques mentioned get broken down, and finally the pros and cons. The content has changed my way of thinking in how both the testing works. When I first heard about both the testing, I was briefly told that both can be used to find the errors and review coding in the software. However, one can be used faster while the other can be used around the end so that the product can be all set for the client. This was a misinterpretation in quite a time for me before finding the blog.

Based on the content of this blog, I would say this is informal and easy to understand when following along the order of it. I do not disagree with this content given by this blog because it helped me understand the ideas of the testing methods even without needing to see it in action. For future practice, I shall try to refer both testing advantages as reference for software testing.

Link to the blog: https://www.testbytes.net/blog/dynamic-testing-and-static-testing/

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

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.

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.

The “Expose Your Ignorance” pattern encourages software apprentices not to feign competence when they don’t know how to do something, but instead to nurture and showcase their ability to learn by admitting that they don’t. According to the writers, the problem is most likely to come up when your managers or team members assume or want confirmation that you know something. You can still reassure people in these situations, but with your capacity to learn instead of by being dishonest about your abilities. In this way you can build trust by showing you can be counted on to figure out how to do what’s needed, even if you can’t do it yet.

Exposing your ignorance doesn’t seem like such a difficult thing if there are no expectations of your knowledge level beforehand, but letting someone know you don’t understand something they thought you did seems almost unbearable, especially in a situation where your ability to do your job depends on understanding it. I hadn’t considered that I might be put under pressure to project an image of having knowledge in an area I don’t, so I’m glad to have some ideas of how to respond to it before it becomes an issue.

Another thing I hadn’t considered was the idea that becoming an expert is something to be avoided, or at least not the main goal. The authors explain that to be a software craftsman, you can’t become confined to a specific domain or skill. This is what naturally happens if you’re too afraid of exposing your ignorance to learn new things. Here too, the idea of having a greater goal to pursue is helpful to me. I would rather be a software craftsman than an expert in one area, because it would help me to keep my options open. Being good at only one thing also means you run the risk that the skill will one day become obsolete.

The advice to publicly post a list of things you don’t understand about your work surprised me. It seems like it would be a painful thing to do, but it does also seem like it would help you get used to putting this pattern into practice. It might end up something I try in the future.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

This week I chose to cover “Craft over Art” from chapter 3. Craft over art is an essential piece to becoming an apprentice. When you are faced with a task, an opportunity to try something different and creative arises. Sometimes you have to sacrifice beautiful work in order to deliver a solid working project. Building… Continue reading Apprenticeship Patterns: Craft Over Art →

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