My reaction to the reading of “Why Doctors Hate their Computers” is that while the program implemented by Epic to try to help streamline the process for doctors, it only made it harder for the doctors, more time consuming, and less revealing about the state of the patients themselves. Overall, the computer systems seemed to make the lives of the doctors, much harder rather then simplifying and streamlining their work. An example of this is when Epic arranged meetings between doctors and administrative staff, and in doing so added more fields to the program to help make the staff’s job easier. In trying to make the job easier for the staff though, it created more work for doctors with questions that previously were an afterthought were now required fields to finish the form for that patient. Another issue that was highlighted in the article was by the author talking to “Susan Sadoughi”, which she highlights the problems with each patient’s “problem list”. While previously this could be used by the doctors to know what to expect when seeing a patient. However after the installation of the medical programs, anyone in the organization could modify these problem lists, and worse there was no conformity amongst those making the changes. “Three people will list the same diagnosis three different ways” is not very helpful to the doctors trying to make the decisions that will help people’s lives. Another problem that I see in this system by Epic is the “stay in your lane” mentality in which ways that assistants would be able to help doctors was removed. For minor things that the assistants were taking care of there should of been cross-training of some sort to help reduce the high workload of the doctor in comparison to the already relatively light workload of the assistant. Despite all of these hardships on the doctors, the real users of this program was not just the doctors but the patients themselves. This program, while it was meant to help the doctors in their job, was really meant to make sure patients had a place to check what medication to use, when their next checkup was, reminders to seek treatment for cancer patients, etc, etc.. While I do not agree with the hardships that are being put on the doctors, I do agree with the sentiment of the man who had this system implement, Gregg Meyer, when he stated, “If computers causes doctors some annoying but improves patient convenience and saves lives isn’t it time we all got on board?”. This hospital system was not the only one affected by technological advances, with the author’s example of the construction supervisor, who also faced almost all of the same problems that doctors faced with their computer systems in his own field. Ultimately I feel that these incorporated systems can cause major headaches to those who have to use them. However, if they are designed properly with the focus on the job itself, simplicity, and no extra ancillary information, then these programs can be massively beneficial. It is when there are too many inputs from too many sources asking for too much out of the program that the true problems with these systems come around.
This blog post will be on the chapter “Expose Your Ignorance” in which the author talks about how, especially as an Apprentice, you should not be afraid to simply ask questions. I feel the author points this out with a very simply line “the need to appear competent is ingrained into people of most industrialized societies”. For myself I can tell you that this is very much the truth, I have been that guy at a job trying to appear competent when I had no idea what I was doing. But, just as the author puts it, you have to be willing to take a few hits to your pride, to progress as a person and ask for help from those you know can. Not only do you learn yourself from this experience, but those around you that you ask for help see you being humbled, and see you growing, in admitting that you needed the help. “Your instincts tell you to hide your ignorance, to feign expert knowledge, but this only stunts your growth and inhibits the work you are trying to accomplish” (David H. Hover). Something else that the author points out is the need to continue this learning process, because this is what it means to be a software craftsman. It is when people stop their continued learning from one subject to the next become experts, and while this is not bad it is not the same path as that of the craftsman. If you stop growing yourself, you can never progress to being a master, but rather you will be highly specialized in one area. This expertise is not a bad thing, but with how broad of a scope software craftsmanship has simply having expertise at one or two subjects puts you nowhere above a Journeyman. Overall I feel this pattern is a very good one for anyone pursuing any subject, because it reminds the reader to stay humble and to ask questions when you do not know. Trying to act like you know something that you do not, will only have other people looking at you like you are a fool, when instead you can show those people your willingness to grow as a person.
This blog post is about the first chapter of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, in which the authors talk about what makes an apprentice and how you can move on and up from that position, eventually to the point of Master if you are determined enough. The author looks to define what is software craftsmanship, and while other people have written similar ideas close to that, none have actually explored what it means to be that craftsman. A point that stuck with me was when the author talks about lessons learned from the Agile Development Movement. They state how when just telling people to do things by a set of rules they would eventually be lost, but when those same people learned the values that underpin said rules, they were able to grow and create new rules for new contexts. The way that the author decided to define software craftsmanship was with the roles from medieval times, that of the Apprentice, Journeyman, and Master, all of which having their own roles in the industry. One thing that stuck out to me personally was when the author began describing what it means to be an Apprentice, in that as an Apprentice it is important to understand there are people much smarter than you which can be resources of knowledge for you. “…-By teaching them to value learning over the appearance of smartness, to relish challenge and to use errors as routes to master” (Self-Theories, pg. 4). As an Apprentice it is also very common and smart for you to be focused inward, focused on growing your knowledge and resources that will eventually be how you transition to a Journeyman. I feel the way the author described the transition into a Journeyman was basically, “one day you just are”, but goes on to describe how it involves more than just the inward focus on growing yourself. As a Journeyman you begin to be more concerned on growing the teams that are around you, and mentoring those around you who are Apprentices working themselves to become the Journeyman. Finally, the author talks about what it means to be a Master software craftsman. This, for me, was one of the most important part of this entire summary of how being a Master software craftsman was more than just your knowledge. Being a Master was more about bringing up those who are around you, some to the point of surpassing your knowledge. “Mastery involves taking that skill and turning it into a magnifying glass that can enhance the skills of others by orders of magnitude”(What Does It Mean to Be a Master?). Overall, I feel the explanation of the Apprentice, Journeyman, and Master of software craftsmanship was very spot on, in that Apprentices are focused on growing themselves. Someone is a Journeyman when they start trying to mentor those around them, as well as growing and developing the team that is around them. Finally, Masters are not just Masters because of their knowledge, but rather how they distribute and spread their knowledge, as well as trying to help grow the industry as a whole.
My blog today is on this article in which the author is talking about what she believes are the goals that software testers should have when working on projects. Right off the bat the author points out that a tester should clearly be trying to find bugs but she also points out that a tester should try to prevent bugs as well. I agree with the way that the author points this out because if a bug can be found in a certain area in a program, the developer probably used the same logic in other places throughout the program. This means that finding that one bug could mean that you have found some flaw in the logic of certain parts of the entire program and should check to see this other possible areas affected by this flawed logic. The author also makes a point that a testers job also includes being able to assess the overall quality of the program, since they are the ones testing it, they should have one of the better understandings on whether it is ready to be delivered or not. I agree with this in the fact that a tester will know the current state of the program, however the tester does not know the full scope of the program or what could still need to be added to it. Another important point the author brings up is to not be afraid to say something about difficulties in the programs usability. Essentially, the author is saying It is worth delaying the release of the program to users if it increases the usability of said program for users. This is an idea that I personally think should be used more in most programs being released, bugs and other difficulties for users at launch create a negative feeling/connotation towards the program/developer, so it is worth delaying a little bit to alleviate these feelings of the customers. In the end it is better for business for these companies if they focus more on testing and quality before release.
My blog today is on this article which talks about some things that a person should consider before starting testing on a program, a sort of checklist to complete before testing. The first thing the author points out is understanding the idea/concept that the client has as in mind as well as understanding the scope of the audience for the program. This is similar to being assigned a project, the first thing I try to do is fully read through and understand the project at hand. If the program is one for something like a bank, then the functionality and worst case testing takes priority, while a program for something like social media would be more focused on aesthetics and testing on different platforms/devices. Once you understand the needs of the client you can start crafting your testing strategy, where you start addressing what kind of testing is applicable to the program that is being tested. The author points out that it is generally inevitable that during testing several testing tools may need to be used, giving the example of how simulating stress/load testing can be very difficult especially if trying to do it with just one machine. Once a test strategy and plan have been setup, you have to then begin planning on how long each phase of testing may take you and to also develop plans for if complications during testing makes it take longer then expected. I agree with the author on this point with it being very important to budget time on a project to prioritize and finish more important aspects the project(or testing) first and then move on to more minimal items. With all of these items on the “checklist” having been thought about, it is time for the actual test plan document to be created. One thing the author brings up in this is there is a standard for these test plans, called “IEEE892 Standard”. After researching this standard I found is a series of 8 documents that fully outlines all the aspects of the testing plan for a program, including items to be tested/not tested, test deliverables, and environmental needs.
In this article, the author is talking about steps to take to actually reduce software defects in programs before release through several steps. The first step seems kind of obvious for a goal but nonetheless it is to stop believing that you can’t put out a program that doesn’t have defects. Defects are nothing more than simple mistakes that could have been avoided but were not, of which these bugs could be trivial or system breaking. So instead of believing that these programs are bound to release with problems and defects, aim to write your programs without any defects. Another thing the author points out is if you are given code to test, not to simply point the finger at the developer of the code being lazy. The people writing the code are not simply trying to skimp on their end to save their time. Instead they are often overworked and simply could have missed something. It is also explained in the article that often the first thing to be done for reducing defects is to develop unit test coverage. However, although this unit test coverage could cover most of the program, it could be ineffective. Something the author points out in his article is the concept of “bug bash” which doesn’t seem like in the end it would be very productive. It is the idea where a team takes the software and tries to break it, and then repair it. While this may provide more knowledge of the software, it seems this kind of practice would be a focusing too much on the knowledge of the software instead of getting a product out to clients. Finally, some of the things that are pointed out in the article is to try to avoid tendencies that will lead to errors in the first place. These sort of tendencies could be things such as when copy and pasting from files, missing some small statement, or could be having files that may be too complex, leading to inattention errors.
This article is about a software tester who is trying to help those new to the field to avoid some mistakes that he has experienced in his career. Some of these mistakes and pitfalls that the author highlights are things like running out of test ideas for a project, missing simple little mistakes, self doubt about issues in the program, and the priority of what to test in a program. For each of these mistakes that an inexperienced tester can run into, the author gives a few examples of what someone can do to in such a situation. One thing the author mentions is when you may be lost on what the testing goal is to ask plenty of relevant questions to help you understand. It is better to admit you’re not clear about something in the project and ask for clarification about it, then to be ignorant of that actual goal. I agree with the author as well on his point about a testers self doubt about a bug they think they have found but are uncertain. In this situation, the author suggests a practice I personally use as well; take a break from the project and come back with a “fresh set of eyes”. This break from the testing gives you time to clear your mind and come back to the project with a new focus. One thing that I learned from this author was the concept of BCA(Brute Cause Analysis) in which two people work together, with one person brainstorming possible bugs and the other thinking about the different ways those bugs could manifest. This can be a very good idea because it is always helpful to be able to see a problem(or bug) from another person’s perspective. One final thing that the author suggests is to trust in your gut when you think you may have found a bug but are not sure. In the worst case you simply find out that it could have been something you did wrong, or in the better case your gut could have payed off.
My blog this week is about an article which talks about things that could possibly go wrong while discussing about testing and how someone could improve their testing. In the article, the author points out several flaws which many testers tend to make. Some of these mistakes testers make include things such as caring about how many tests there are instead of the quality of the tests, how many people have a hard time adapting to creating new tests as a test case evolves and when people believe there is only one way to test something.
I thought the author had a lot of good reasoning behind his thoughts on testers, which can be applied to more than just testers too. This applies especially to his first point which pertains to when people care more about the volume of test cases they have written versus the quality of those test cases. The author’s point, which I agree with, is that it does not matter how many test cases you write, if they do nothing to actually test the code, than they are completely useless. This thought also makes me want to pay more attention to the test’s that I write to make sure that they are effective and proper to what I am actually testing for. Another comment the author made which makes me want to look more at the way that I move through testing is that many people have a hard time adapting their tests as the strategy of said tests changes. Being able to change and adapt your tests as the test strategy changes shows a true understanding of the purpose of the testing that is happening. Finally the author brings up the point that people often have the thought that if they are testing something one way, they have tested that thing fully. However, if they run the same test with a different data set they could discover some new bug that you would not have seen before. This is another good example by the author of pointing out a flaw that many people can and tend to make, and one that I plan to focus more on myself.
My blog this week will be based on this article that argues that a certain form of testing, “lean testing”, is far more helpful than something like normal unit testing and test driven development. The author goes on to explain their way of testing, “lean testing”, is essentially focusing on different kinds of tests then unit tests which will be more beneficial with the finite amount of time you may have to get certain projects done. With unit testing, you tend to test bounds of the program that will affect very few users and it is better to focus the tests on more real world scenarios that a user might encounter.
I feel the author raises a good point in this testing, to focus tests more on what a user of a program will likely run into rather then on the bounds of the program which very few to no users will encounter. With that though, I do still feel it is important to at least include some tests to make sure the bounds of a program are working and will notify the user of such. Another thing that the author included was the three dimensions they think best help to follow in testing and that is speed, cost, and the most important one; confidence. This quote from the article which I feel reflects what the author is trying to make clear in the article is from Kent C. Dodds, who said “The more your tests resemble the way your software is used, the more confidence they can give you”. The author also provides another reasoning for this testing of what the user is more likely to encounter when using the program, and that is that testing those cases tend to cover more of the code then something such as boundary testing. One final point that the author brings up that I think helps reinforce their way of “lean testing”, is that unit test code is often not resilient to code changes. While some of the test code may be reusable, most of it is often not.