structure, maintaining user satisfaction throughout, and finally delivering the software product. This requires the team to have competencies in coding, analysis, and teamwork. In addition, the team needs familiarity with some programming language, such as Java and JavaScript, which Smith knew. What Smith didn’t yet know was that the tasks he had been given were still relatively simple tasks compared to what is typical in the software industry. Nevertheless, with this preparation, Smith marched toward his internship interview.
Figure 1.2 What software engineering is from the eyes of a student.
1.3 From Internship to Industry
With some luck, Smith managed to join the company TravelEssence as an intern trainee. Dave the interviewer saw some potential in Smith. Dave was particularly intrigued that Smith managed to draw the picture in Figure 1.2. Most students couldn’t, and would get stuck if they even attempted to.
TravelEssence is a fictitious company that we will be using as an example throughout this book. TravelEssence provides online hotel booking services for travelers (see Figure 1.3). In addition, TravelEssence provides Software as a Service (SaaS) for the operation of hotels. SaaS means that the owner of the software, in this case TravelEssence, provides software as a service over the internet and the clients pay a monthly fee. Hotels can sign up and use the TravelEssence service to check-in and check-out their customers, print bills, compute taxes, etc.
Smith’s stint in TravelEssence provided a whole new experience. To him, his new colleagues seemed to come from two groups: those who stated what they wanted the software to do, and those who wrote and tested the software. Figure 1.4 highlights the dramatic changes Smith experienced. While everyone seemed to speak English, they used words that he did not understand, especially the first group. As a diligent person, Smith compiled a list of some of this jargon.
Figure 1.3 TravelEssence home page.
Figure 1.4 What software engineering is from the eyes of a student after internship.
Book. To sell or reserve rooms ahead of time.
No-Show. A guest who made a room reservation but did not check in.
Skipper. A guest who left with no intention of paying for the room.
PMS. Property Inventory Management System, which maintained records of items owned by the hotel such as items in each room including televisions, beds, hairdryers, etc.
POS. Point of Sale Systems (used in restaurants/outlets) that automated the sale of items and managed purchases with credit or debit cards.
It took Smith a little while to get on “speaking terms” with his new colleagues and mentors.
In his student days, Smith always wrote code from scratch, starting with an empty sheet of paper. However, at TravelEssence it was mostly about implementing enhancements to some existing code. The amount of code that Smith saw was way above the toy problems he came across as a student. His development colleagues did not trust him to make any major changes to the system. Developers in TravelEssence emphasized code reviews heavily and stressed the importance of “Do no harm” repeatedly. They would repeatedly test his understanding of terminology and their way of working. Smith felt embarrassed when he could not reply confidently. He started to understand the importance of reviewing and testing his work. After his internship, Smith attempted to summarize what he understood software engineering to be (see Figure 1.4). This was quite similar to what he thought before his internship (see Figure 1.2), but with new knowledge (indicated in red) and an emphasis on testing and doing no harm as he coded changes to the software product. Smith came to recognize the importance of knowledge in different areas, not just about the code, but also about the problem domain (in this case, about hotel management), and the technologies that were being used.
Competency not only involved analysis, coding, and teamwork, but also extensive testing to ensure that Smith did no harm. Understanding programming languages was no longer sufficient; a good working knowledge of the technology stack was critical. A technology stack is the set of software technologies, often called the building blocks, that are used to create a software product. Smith was familiar with multiple technologies that were being used including Java, JavaScript, MongoDB, and MySQL. Never mind if you do not know these specific terms.
Note: There are myriads of technology stacks available, and it is not possible for anyone to learn them all. Nevertheless, our recommendation to students is to gain familiarity with a relevant technology stack of your choice.
Smith graduated and was employed at TravelEssence. A few years later, at a get-together, Smith and his old classmates shared their newfound experiences in the real commercial world. At this occasion Smith said: “At TravelEssence even though everyone seemed to be using different terminology, and everyone did things differently, there seemed to be something common to what they were all doing.” One of his old classmates asked Smith if he could explain more, but Smith just shook his head and said, “I don’t know exactly what it is.”
Figure 1.5 What software engineering is from the eyes of a young professional.
Some years later, Smith became a technical lead for a small group at Travel-Essence. As a technical lead he found himself continuously thinking about that discussion with his old classmates as he tried to figure out just what it was that was common about the way everyone worked at TravelEssence.
One evening the old classmates got together again. This time the discussions were a blend between technologies and people management. The old classmates were also talking more about their experiences dealing with people including their colleagues, managers, and their customers; consequently, they were talking more about the way work got done in their organizations. Managing stakeholders and their expectations became more important as they started to take on more senior positions.
After the meeting with classmates, Smith started to draw what he then thought software engineering was about (see Figure 1.5). The changes compared to Smith’s internship experience are highlighted in red.
Stakeholder collaboration played an important part of Smith’s work. Collaborating well involved having an agreed-on set of values, principles, and practices. These values included agreeing upon a common goal, and respecting and trusting team members, as well as being responsible and dependable. All of these values are qualities of a good and competent team player. Principles include, for instance, having frequent and regular feedback, and fixing bugs as soon as they are detected. All of these principles identify good behaviors in a team. Practices are specific things the team will do to deliver what is expected of the team consistent with the above values and principles, as well as good quality software.
1.4 Journey into the Software Engineering Profession
