First post on CS-443

Hi everyone. This is the first blog post on CS-443 Software Quality Assurance and Testing.

 

Advertisements

The Software Craftsman: Chapters 15 & 16

In chapter 15, “Pragmatic Craftsmanship”, author Mancuso defines what pragmatic craftsmanship is. He states craftsmanship without pragmatism is not craftsmanship. A craftsman’s primary focus is customer satisfaction. Besides quality, time and cost are part of this satisfaction. Job as craftsmen is to lower the cost of quality to a point that it is not a concern anymore. For that, we need to master our practices and be pragmatic. We need to understand the value that certain practices bring in different contexts. When dealing with craftsmen, clients should never pay more for quality.

Furthermore, this chapter, busts the myth that quality is costly. Cheap and average code is good enough, maybe in the short term, but never in the medium and long term. Regardless of what managers and product owners say, they all expect quality. They would always choose quality if they didn’t need to trade it off for something else, like time and money.

What I learnt from this chapter is the true meaning of code. I used to think that code is a piece of software which perform certain task. Of course it needs to accomplish the task successfully, but also more importantly it should be well-crafted in every possible way. It should also provide a long term value.

Chapter 16, “A Career as a Software Craftsman” discuss what it is to be a craftsman and how to have a successful and fulfilling career. Honesty and courage are essential qualities of a software craftsman. Software craftsmen are passionate about software development and their profession. Being a craftsman is more than being a good developer who writes code well and delivers business value. It’s a lifestyle. Moreover, being a craftsman means to be curious and experiment with new things. It means to be pragmatic, always looking for simple solutions and using the best tools for the job.

Yes, being a software developer is beyond awesome. Being known as a Software Craftsman (hopefully in future) is the best decision I made in my life. It’s a life where I choose to do things well, to be the best I can be. But the tile comes with responsibilities. I should be honest, courage, and full transparent, which I will be.

 

The Software Craftsman: Chapters 13 & 14

In chapter 13, “Culture of Learning”, author Mancuso talks about different things developers can do to create a culture of learning. According to author, we will never change an organization by forcing people to adopt a new process or different practices. Instead, we should create a culture of learning, where people can find their own motivation to make things better. Creating a culture of learning is one of the most efficient ways of injecting passion into a company. We should let developers decide how, when, and what they want to learn. With this freedom, developers have much better chance of creating and embracing a culture of learning.

Author lists some of the things developers can do to create a learning environment. He suggests in: Starting a book club; Having a tech launch; Having a group discussions; Switching project for an iteration; Switching projects for a few hours; Conducting group code reviews; Having hands-on coding sessions.

From this chapter, I learnt how to focus upon establishing a rhythm. Software developing isn’t an easy task. We go through a lots of stress, which makes it difficult to get back to work, catch the ongoing rhythm, and keep engage ourselves into the culture of learning. I will from now follow the author suggestion that is, to having a healthy community, and keeping the sessions going. I will stop finding excuses and be willing to start new things.

Chapter 14 titled “Driving Technical Changes” revolves around several types of skeptics and how to convince them to be more open to different ideas. Author argues to be successful, we need to understand how to deal with all the different types of people we will need to interact with and convince along the way. Being good at what we do, being able to communicate clearly and most critical, having the capacity to build up trust are the essential skills for any for any developer. Setting ourselves up is equally important to be successful. We need to have understanding of whom we are speaking to, and appreciate the reasons for each person’s thinking.

This chapter helped to boost my confidence level. I learnt how to be be brave and say everything I think, no matter what. I shouldn’t be afraid to engage in debates with my co-workers. Whatever I do, I should be that the product I deliver adds value to your customers. This way, I don’t need to keep convincing my manager.

Reflection: Sprint 6

This sprint we continued to work on our previous issue APTS-296. The actual issue was not located at all in the ng2-arms directory but in a npm webpack. Npm webpack was in another github directory. The list is listed below:

https://github.com/AMPATH/ng2-opemmrs-formentry

Moreover, we were not able to use Travis CI since it is not the ng2-amrs repo. We asked the AMPATH slack team for help and clarification on issue. They use a question model to load the form, a question factory that converts the JSON to model. AMPATH switched to using a dynamic JSON form schema, then render that form. Question model is then used to construct a form node. Form node basically consists of a question model, and the angular form control. The form render (html file) then consume the form-node and then render the form.

This is how the JSON file looks like:

“label”: “Next appointment”,
“isExpanded”: “true”,
“questions”: [
{
“label”: “Return to clinic Date:”,
“type”: “obs”,
“required”: “true”,
“questionOptions”: {
“concept”: “a8a666ba-1350-11df-a1f1-0026b9348838”,
“rendering”: “date”,
“showWeeks”: true,
“weeksList”: [2,4,6,8,12,16,24]

Since we had no control over the JSON schema, we contacted admin over JIRA who has control over the form schema. Admin then updated the schema to include 24 and 36 weeks. We tested confirming that it was shown in the drop-down. Finally, the issue was fixed and closed.

The Software Craftsman: Chapters 11 & 12

Chapter 11, “Interview Anti-Patterns” cover interview anti-patterns that should be avoided. Major things to be remember are:

  • Don’t be a smart-ass interviewer
  • Don’t use brainteasers
  • Don’t ask questions to which you don’t know the answers
  • Don’t try to make candidate look like a fool
  • Don’t block the internet
  • Don’t code on a piece of paper
  • Don’t use algorithms
  • Don’t conduct phone interviews

The next chapter “The Cost of Low Moral” discuss about the cost of low morale and how it can be harmful to projects and companies. Low morale can be one of the main reasons for a software project to fail. Low morale could bring a whole company to a halt. Embracing Agile processes and ideology is essential for providing the right environment for improving morale, but when it comes to developers, we need more than that. The best person to motivate a developer is another developer.

I agree all the points author Mancuso had mentioned. My personal favorite is: Don’t block the internet. Removing Internet access just doesn’t make sense. No one knows everything off the top of their heads, and we all do have access to the Internet at work.

The Software Craftsman: Chapters 9 & 10

Chapter 9 “Recruitment” revolves around different ways of attracting software craftsmen to a certain organizations, and suggestions to craft job descriptions.

Mancuso argues hiring people purely based on technical knowledge will not help to drive technical and cultural changes. The focus of a job description should be on detailing the expected attitude and responsibilities, types of projects, technologies used (not required), and values and culture of the company. The companies need to create filters in order to pre-select the ones they feel have a better chance of satisfying their needs. Organizations should be more specific with our filtering criteria. But whichever filter criteria being applied, we will always filter some good developers out. Thus, the first thing is to define what a good developer means. Furthermore,  the time wasted interviewing wrong candidates is the problem that must be addressed.

The next chapter “Interviewing Software Craftsmen”, answers, how companies and developers can identify whether they will have a productive partnership. Collaboration and empowerment are key for any successful team. The number of questions (and also the types of questions) asked by an interviewee may be a good indication of how much this person can collaborate and contribute to the business. As a candidate we should be aware of – is the interviewer more interested in binary answers to technical questions or more interested in knowing us better?During an interview, it is important to understand that we are not begging for a job. We are doing a business negotiation. Before signing any contracts, the most important aspect of providing a service is to understand and measure the risks and rewards of that negotiation.

Moreover, author defines what a good interview is. A good interview is like a good and informal chat between passionate developers. It’s an exchange of information: a good debate about techniques, tools, challenges, and approaches to software development.When interviewing, one should look for talent, attitude, passion, and potential, not knowledge of specific technologies. Looking at submitted code is a far better way to filter candidates than looking at CVs or conducting phone interviews.

These chapters taught me how to figure out, which job suits for me and my future career. I will take interview as an opportunity to understand more about the company and the people whom I will, potentially, be working with.