This week I read a post of Joel Spolsky, the CEO of Stack Overflow. This post talks about an approach of designing a software product that is “Activity Based Planning.” The main idea of this method is to figure out the activity that the user is doing and focus on making it easy to accomplish that activity. Some examples will show how to apply this approach in designing a product. First example, you’ve decided to make a web site that lets people create greeting cards. Using a somewhat naïve approach, you might come up with a list of features like this: Add text to card, Add picture to card, Get predesigned card from library, Send card (Using email or printing it out). This way of thinking would lead to a program that starts out with a blank card, with menu items for adding text, pictures, loading cards from a library, and sending cards. And then what the user is going to have to do is sit down and browse through the menus, trying to figure out all the commands available, and then do their own synthesis of how to put these atomic commands together to create a card. Now, with an approach of activity based planning, you need to come up with a list of activities that users might do. So, you talk to your potential users, and you come up with this “top three” list: Birthday Greeting, Party Invitation, and Anniversary Greeting. Now, instead of thinking about your program from programmer perspective (in terms of what features you need to have to make a card), you’re thinking about it like the user, in terms of, what activities is the user doing, specifically:

1. Sending a birthday card
2. Planning a party, and inviting people to it
3. Sending an anniversary card

Suddenly, there are new ideas of designing. Instead of starting with a blank card, you might start with a menu like this:

What do you want to do?

• Send a birthday card
• Send an anniversary card
• Send a party invitation
• Start with a blank card

Suddenly users will find it much easier to get started with your program, without browsing around on the menus, since the program will virtually lead them through the steps to complete the activity. The three activities suggest some great features which you might want to add. For example, if you’re sending a birthday or anniversary card, you might want to be reminded next year to send a card to the same person, so you might add a checkbox that says “remind me next year”.

Activity based planning is even more important when you are working on version two of a product that people are already using. We should observe a sample of customers to see what they are using your program for and which activities they go with your program. We could add more activities to program or make existing activities more suitable to certain groups of customers. Therefore, activity based planning is helpful in the initial version of your application, where you have to make guesses about what people want to do, but it’s even more helpful when you’re planning the upgrade, because you understand what your customers are doing.

In conclusion, designing good software takes about six steps:

1. Invent some users
2. Figure out the important activities
3. Figure out the user model— how the user will expect to accomplish those activities
4. Sketch out the first draft of the design
5. Iterate over your design again and again, making it easier and easier until it’s well within the capabilities of your imaginary users
6. Watch real humans trying to use your software. Note the areas where people have trouble, which probably demonstrate areas where the program model isn’t matching the user model

Article: https://www.joelonsoftware.com/2000/05/09/the-process-of-designing-a-product/

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

So for this week, I have decided to read about “Behavioral-Driven Development” from the Future Processing blog. The reason I have chosen this blog is because usually I hear this development does help with the established practices of Test-Driven Development and make it more accessible and effective. This will help me understand why some have suggested in using this development and see the problems with it that make it difficult to give even an introduction.

For this blog post, it goes over the motivations of introducing Behavioral-Driven Development, why to use it, and the typical problems with it. With the motivations listed, there is public distress, test automation, and better Test-Driven Development. Public distress is from those who want it to be introduced for the sake of introducing it, teat automation is from wanting to automate tests which the development does not require automation, and better test-driven development is from that the development is only understood as a higher layer of requirements.  There are many reasons listed in why this development should be used but the main thing is it is a communication tool. This tool for the main reasons listed can help to answer the question of how the problem will be solved, clarifies when we consider that the program solves our problem, and discovers what should happen when an unusual scenario comes. When it comes to typical problems with this development, there are incomprehensible scenarios such as no explicit dictionary, these scenarios becoming an unnecessary overhead, and the use of it in teams.  In conclusion, ideological use of this development is demanding and difficult. But it is always worth trying and adapting technics like this communication tool and it might lead to the right software for the needs of a client.

What I think is useful about this blog is it goes all the way to express this development as a communication tool. From this blog, it goes over the way how this development introduced generally, gives lists of the uses of the development and the problems with it, and even has a scenario to show how it works with further explanation. The content of this blog has definitely change my way of thinking with this development.

Based on the content of this blog, I would say that this blog is a little difficult to understand at first if you don’t know about Test-Driven Development. However, I don’t disagree with any of this content because it clarifies some things about Behavioral-Driven Development such as understanding the perspective of a user with this development. For future practice, I will try to use this development with a given when and then template.

Link to the blog: https://www.future-processing.pl/blog/behaviour-driven-development/

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.

This week’s post is going to be about Dynamic and Static testing from testbytes. Static and Dynamic testing are the two major methods of software testing.

Static Testing is done manually or with a set of tools. This type of testing is useful in finding flaws. It is mainly done in the early stages of the development cycle, also referred to as verification testing. Specifications, design documents, source code, test plans, test scripts, test cases, and web content, all have to pass the static testing. Some advantages of Static Testing are: identifying flaws in the code since it is done in the early stage of development, the testing is conducted by trained software developers, and it is a fast and easy way to find and fix errors. Some disadvantage to using it are:  it demands a great amount of time when you’re doing it manually, not all automated tool works with the language, and that automated tools only scans the code.

Dynamic Testing is done when the code is executed and checks how the software performs in a run-time environment. This testing checks the functional behavior and performance of the system. The purpose of this testing is to ensure that the finished product is designed according to the specification given by the clients. It is also known as validation or execution testing. Some advantages to Dynamic Testing is that it identifies weak areas in a run-time environment and it can be applied to any application. Some disadvantages are: it is not easy to find a trained professional for dynamic testing, and it is difficult to trace vulnerability in the code and would take longer to fix the problem.

At first, I thought that Static and Dynamic testing are different kinds of testing but it’s actually more like a primary and secondary test. I really like this blog because it lists the advantages and disadvantages, for me it makes it easier to understand if the layout is like that. Also, they mentioned that eighty-five percent of flaws of the software can be detected during Static Testing, I think that is really interesting. You would’ve thought that most of the flaws in the software would be found in the Dynamic Testing where they test the end product.

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

The “Reflect As You Work” pattern reminded me right away of the agile software development practice “inspect and adapt.” This practice is mentioned later in the writing as a more formal and specific version of this pattern, whereas an apprentice reflecting as they work involves self-analysis which encompasses all the projects they’ve worked on. The writers recommend periodically asking yourself whether your practices are up to date or becoming obsolete. They ask you to reflect on both the positives and the negatives about your current work, recognize how things got that way, and think about how the negatives could be improved. As one way of helping to apply this pattern, they suggest creating personal practices maps. Unfortunately the source they give for examples of this is gone, so I’m not sure what this ought to look like. I can take note of any changes in my approach as time goes on, however.

This pattern is all about maximizing the amount of useful information you get from your experiences, and utilizing it will make the difference between being an experienced developer and a skilled one; you can have lots of experiences without extracting much meaningful knowledge out of them. Therefore, the writers emphasize that your goal should be to become skilled, not experienced. I found the highlighting of this difference interesting, and it seems intuitively right that it’s possible to become experienced without gaining skill.

One of the authors is used as an example of the power of noticing and reflecting. He explained to his new teammates the pair programming technique the team used which hadn’t really been discussed, and which had simply emerged from their experiences. Once he’d noticed that this was a specific programming practice that should have a name, he blogged about it, and that quickly led him to writing columns for a prominent Software QA website. For me this connected to and reinforced broader lessons I’d already been taught about the importance of observation and noticing; the person who discovered the smallpox vaccine didn’t invent anything, just noticed that people who’d had cowpox didn’t get smallpox.

The author’s experience is also an example of another application of this pattern, which is to observe and reflect on the practices of other developers and adapt your own accordingly.

It’s already my natural inclination to reflect on what I do, so it should be no problem to incorporate this practice into my future profession.

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

In this Apprenticeship pattern “The Long Road”, it gives us an overview about “the journey” that an apprentice goes through to study, learn, and develop his own craft. Considering that there may be shortcuts towards mastering your craft, it always best to let the journey carry you as a developer because the little things you experience along the way will help you become better overall. Not only the experience is important, but it is also important to understand that there isn’t a literal “mastered” status for a developer where you stop learning or stop to further develop your craft. It is always ongoing because there will always be something new in the programming realm to learn and study for the simple fact that technology is always a growing and advancing industry.

“First, accept the fact that you may be considered a bit strange for what you want to become. Second, keep your focus on the long term. During your apprenticeship, value learning and long-term growth opportunities over salary and traditional notions of leadership. People aspiring to become masters of software craftsmanship need to plan for the long term. This long (yet bright) journey will bring you a rich set of abilities. You will become skilled at learning, problem solving, and developing strong relationships with your customers. You will come to wield knowledge and technology as the samurai uses his short and long swords. You will come to comprehend and appreciate the deeper truths of software development. But all this will take time.”

This idea stood out to me the most and it definitely changed the way I think about the journey on mastering my craft as a developer. Back when I was just learning my first programming language, which was C++, I thought that quickly becoming proficient proved that I was a “master” at it. Now I realized that wasn’t the case. After realizing this, the process of mastering a craft has to take time. The process can involve making mistakes, but that’s fine. For me as an individual, I learn best after I make the mistakes so I know what not to do and I know how to approach the problem the right way.

Considering that I do want to become a video game developer, this pattern also taught me that aspirations to be in leadership positions such as a manager or other promotional positions can get in the way of the learning and growth opportunities on becoming a master craftsman. Now when I approach the position of a video game developer, I’ll be sure to love the journey to grow and become the best developer and programmer I can be.

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

This week, I read the apprenticeship pattern “Dig Deeper”, and as the title suggests, this pattern was about trying to gather a much lower level understanding of some of the tools and the libraries that we use daily. The author acknowledged the fact that you do not always need to be an expert in everything to get the job done, sometimes a superficial level of many technologies is more valuable. This pattern suggested that a superficial level of understanding is needed in times where you need to just get something working, maybe you have a deadline, or you are satisfied with the way the product performs. This pattern also did a fantastic job of highlighting the value of digging deeper.

Like many of the patterns in this book, if applied, they will make you more desirable as an engineer. This pattern will not always lead to you acquiring a new skill, but rather it will sharpen your skills and give you an understanding so deep that you may find new ways to use the tools that you’ve always been using, as well as finding new solutions to that problem that has been glaring at you. One personal experience that I’ve had with this pattern was during an internship. I’ve previously had a very basic understanding of REST, and for the most part, that was enough for me to get by, but I was eventually assigned a task that required knowing more than just the basic GET, POST, PUSH, and DELETE requests. This task forced me to dig deeper into rest to understanding things like authentication, query parameters, and other low level details. Having been forced to dig deeper, I now have a much better understanding of REST and with this understanding comes the freedom to write better APIs as well as being able to diagnose issues much more quickly.

I find this pattern extremely useful, and although it may not always be possible/viable to dig deeper when working on a project, I now believe that it is always worth it to make the effort because the benefits are almost always worth the time investment.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Sweeping the Floor is a saying for doing the dirty work that no one else wants to do. This pattern highlights what you can do to stand out as the new guy on the team and make yourself valuable to them. This pattern was an excellent read, you can read it yourself here: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch04s05.html

The pattern makes it obvious, almost every team has a job that no one WANTS to do. I have seen this at my own jobs. Things like cleaning, writing well thought-out documentation,  and even answering the phone are some of the small tasks that people would rather not do. Step in and volunteer to do those tasks. This will enable you to gain trust and socialize with the team so you can get your foot in the door. The authors go on to talk about how there are some negatives to sweeping the floor. However, In my opinion they are all avoidable. These negatives would be getting stuck as the teams scrub (someone who they make do all the menial tasks and never ask more of), or you will be too intimidated to try and step out of your comfort zone. Both of these are avoidable by being more assertive once you’ve gained trust and a place on the team.

I really enjoyed this pattern because it will be extremely relevant to me in the upcoming future. I am applying to (what feels like) hundreds of jobs to try and join a team when I graduate. I know I will have to prove myself and this pattern has given me a way to do it. Take pride in the small jobs and do them well, this will help you make a stand in your team. The only thing about this pattern I didn’t like was the fact that they added consequences to it. I feel like that really brought down the overall inspiration of the pattern. The consequences weren’t on my mind when I was reading the pattern until, of course, I read that part. They should have stressed that you need to be confident in your abilities to learn and continue to try and climb the totem pole.

Overall, the pattern is an excellent inspirational read for someone who just joined a team and are looking to prove themselves. I can certainly see myself doing this in my future jobs.

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

This pattern is one among the many which I have drawn so much knowledge and think will go a long way to help me grow in my future employment activities as far as software development is concerned. Educationists will tell you that learning is a gradual process and I know it’s not going to end in the classroom when the time come and I am out of the classroom to the field to face the world. This pattern has just reaffirmed that learning is still going to take place afterward. It is really hard as David H. Hoover admitted to say you don’t know when they expect you to know what they are asking you to deliver. But for my own good I will not be tempted to give quick answers to questions that will put me in trouble later on. Again, this  pattern has also given me the idea that as an apprentice, my goal is not to become an expert but that will come naturally as I go the journey and explore deep into an interesting areas of  learning.

I strongly agreed with the point that when your answer questions, you become clarified of your own knowledge. This is true because, anytime I help someone do something or explain something to someone, I will never forget that subject again; that is stick in my head forever. I used to be shy to speech in public even if I know the answer but as I grow and become more familiar with difference group of people, things began to change. From then,  anytime a question is asked in the mixed of people, I always try to be first to respond  to it if only I have an idea of what is being asked  because I know how it help me in understanding the scope of my knowledge better.

I have been trying to cherry pick these patterns but I realized going through all of them will help me more because, they are interconnected. So far, with what I have learned, all the patterns has something unique that I think if carefully adopted will go a long way to help me deal with all the problems I will be facing as an inexperience apprentice.

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

The context for this pattern, as described by the authors, is that you have found gaps in you skill set that are effecting your everyday work. The problem here is that your knowledge of essential tools and concepts is lagging behind that of your coworkers but you are expected to already have this knowledge as a prerequisite for being a productive member of the team. The authors explain that this particular pattern goes hand-in-hand with the “Expose Your Ignorance Pattern.” They stress the importance of adopting both of these patterns simultaneously as just adhering to one or the other can present problems of their own. For instance, by only exposing your ignorance and never confronting it you may end up in a constant state of ignorance and being overly dependent on other team members when it comes to completing essential tasks relating to the project at hand.  On the other hand, if you only confront your ignorance without ever exposing it you may be missing out on valuable insights your team members could provide you not to mention the fact that you may spend too much time trying to learn specific concepts that could have been easily explained to you by a team member who already has the knowledge you are seeking. According to the authors, the solution to this problem is to “strike a delicate balance” between these two patterns in order to ensure you are learning the essential skills necessary for your role without wasting to much time and allowing you to be as productive as possible.

I found this pattern to be quite relatable in my current role as a Security Analyst. When I first joined the team I had very little knowledge when it came to essential information security concepts. For example, in security it is crucial to have a fundamental understanding of how the different layers in the OSI network model function. This can be quite overwhelming at first considering that each of the seven layers have different functionality along with a multitude of associated protocols that they must adhere to. Luckily my team has been really supportive in helping me gain the necessary knowledge and skills by giving me practice problems and either providing me the resources necessary to learn essential skills or pointing me in the right direction to where I can find helpful resources. I think up to this point I’ve been able to maintain a healthy balance of exposing and confronting my ignorance but the advice provided in this pattern will definitely be useful going forward.

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.