►Notes from lecture 1 – Goals and skills
Notes from lecture 1 – Goals and skills
1 What this course is about
2 The skills this course aims to develop
3 The structure of this class

Notes from lecture 1 – Goals and skills

1 What this course is about

The goal of the course is to lift your software development skills from working with small programs (think CS 111) to designing and building software systems.

What makes software a system rather than a program is not the number of lines of code nor its algorithmic complexity. A software system is a collection of programs that all work together to form an operational whole with well-defined structure and well specified interaction with its environment. As such a software system has a few more characteristics:

  • Supports configuration for adapting to the requirements of its environment;

  • Maintains a stable operational phase even under adversarial load, and supports graceful termination even under irregular conditions.

Example: A software system for playing a board game should:

  • Consist of well-defined parts representing different elements of the game (like the board, players, and so on);

  • Create the overall game by linking together those parts;

  • Let its users configure whether players use a GUI or a textual interface, or whether the rules checker will use this or that version of the rules;

  • Maintain an operational mode where users can register, initiate and play games etc even when some users attempt to cheat or connections drop, and terminate without damaging the host environment or the users’ environment (those are not always the same ...) both when termination is intentional and when unexpected.

The above example illustrates that building a software system involves dealing with dimensions of design complexity that go well beyond those you encountered when writing small programs. To make matters worse, decisions that developers make as early as when the system is still a prototype (such as the programming language) can stick around for a very long time. See for instance all the legacy COBOL code in bank software systems. It is still there under layers of wrappers of C++, Java, and JavaScript.

So how can you cope with this great complexity? You need to develop a set of skills that will help you take good care of your code as it grows from a prototype to a full fledged system.

2 The skills this course aims to develop

Software construction focuses on three kinds of skills: technical, process, and personal skills.

Technical skills should not be confused with technological skills. We are not going to focus on a particular technology – that would be a lost battle from the get-go, given the rate of change in the field. Instead we will focus on techniques and ideas that are fundamental and will be applicable as the technological landscape changes. In particular the course aims to give you plenty of opportunities and guidance to exercise:

  • Modular development;

  • Design of interfaces and protocols;

  • Integration of (heterogeneous) components in a system;

  • (continuous) Testing with systematically constructed test harnesses.

Be prepared to see that while practicing one of the above you will start reconsidering earlier decisions. In other words, these skills are not isolated but form a highly connected feedback loop. Be also ready to discover that the languages and tools that you pick to work on the courses’ assignments may not support you sufficiently to do the above. As you cultivate your technical skills, you may realize that you have outgrown your tools of the trade and that those limit you instead of serve you.

Process skills help you work effectively on a project: meeting deadlines, dealing with client requirements, and satisfying quality standards. Software development processes have become a highly debated topic since the days of the legendary waterfall model — indeed it is an actual legend whose origins, purpose and existence are often misrepresented. Since then many proposals have appeared (e.g. agile, XP, test-driven, ...) emphasizing the importance of short-cycle adaptive evolution of software rather than the discrete, serial approach of the waterfall model. In this course, we will not follow a particular model but instead we will follow the steps to answer the fundamental questions behind every software design process:

  • What is the goal of our system?

  • What are the pieces that are involved in our system and how do they relate to other things (internal and external to the system)?

  • What are the use cases of the system?

  • Focusing on one use case (the most important):

    • How can it be decomposed into parts?

    • What are the requirements for those parts?

    • How can we represent those parts as components and what is their interface?

    • Can we implement these components?

    • Can we gain confidence that each component in separation is correct (e.g. unit testing)?

    • Can we integrate the components in an operational prototype?

    • Can we gain confidence that the integration is correct(e.g. integration testing)?

    • What is the next use case we should analyze?

Example Here is how the above plays out if we want to implement some automation support for a small physical store:

  • Our goal is to implement a system that allows to automate the sales, inventory and accounting operations of the store;

  • The pieces include: customers(external), sales persons (external), inventory employees (external), accountants (external), registry (internal), printer (internal), inventory (internal), bank (external)

  • Some uses cases are: a customer wants to buy some products, inventory employees want to make orders to restock a store, the accountants want to balance the books and pay bills;

  • We will focus first on the purchase-of-products use case: the customer brings products to the registry, the sales person rings them in, the customer swipes credit card, the registry contacts (i) the bank to get acknowledgment for available funds and charge the customer’s account; (ii) the printer to output the receipt and (ii) the inventory to alert it that the purchased products have been removed from the shelves of the store;

  • One component involved is a shopping cart (imagine it runs some software) component that collects the information of all the products that customers bring to the registry and offers an interface to add a product, remove a product, ask for total value of its contents, and pay for the products it holds;

  • We implement and unit test the shopping cart and each other component;

  • We connect the components and test their connections;

  • We move to the next use case.

The weekly homework assignments are designed to have you work through this process on a regular basis. They will state the goals, provide guidance to identify actors and use cases but let you decide on the components and their interfaces. Finally, some central interfaces will be provided to you, as in real life, so that we can connect each others components.

Personal skills are necessary for a software developer as software development is only partly a technical discipline. A big part of software development is communicating with other people. First, developers have to communicate with each other since they work mostly in teams and often inherit code or use components that others have built. Second, they have to communicate with their managers to explain to them what they have built, to requirement engineers to understand what the clients need, and to QA engineers to understand issues with their code. Put differently, a software developer needs to be able to (i) effectively explain their code both at a high-level and with all the nitty-gritty detail; (ii) provide constructive feedback to others code on the fly for a problem they understand well; and (iii) be open to critique from others.

This last part is particularly important as a developers ego easily becomes an obstacle to delivering successful artifacts. Programmers should disassociate themselves from their code and examine it and let others examine it as if it was a newly found artifact from the depths of history.

The course aims to simulate these real world conditions by giving you the opportunity to play four different roles:

  • Members of a team of two who will practice pair programming and learn to communicate (and cope) with a partner on a daily basis;

  • Codewalkers who will explain their code and especially its bugs, issues and imperfections to your peers and be open to accept continuous constructive criticism;

  • Audience members who will have to understand and provide constructive feedback to code they see for the first time;

  • Panelists who will direct the discussion during each codewalk and compile a succinct memo with feedback for the codewalkers.

For each codewalk to be a learning experience for all, we have to agree on the ethos of the class. Insulting behavior towards members of the audience or the codewalkers will be shot down immediately. Panelists, feel free to ask questions about the presented code or to suggest concrete improvement within the language and tool framework the codewalkers have picked (my language has feature X that can do Y is not helpful). Moreover speak to point out issues with the design and the code, but be respectful, constructive and criticize the code not the people. Codewalkers, never be defensive. Accept criticism or show why a comment is wrong in a concrete way (e.g. with a unit test).

As a final note, developers need to be able to spot and resolve ambiguity. Clients often leave out crucial details about what they want — if we assume they know exactly what they want — or they make contradictory requests. Similar issues arise when developers communicate with their managers or even with each other. To imitate these extremely common situations, some assignments in this course are underspecified. So if you think something is missing or something is not precise, just like in the real world, ask for clarification!

3 The structure of this class

In this class we will build a system for playing a board game. You will build it in parts corresponding to the assignments, which will be due roughly every week. Each assignment will go roughly like this: First you design and think the part of the system you need to build, and you will create tests that capture the essential requirements of the part of the system you are designing. Then you will execute your design, and you will get real-time, continuous feedback about your implementation by testing it against the collection of the whole class’s tests.

For most of the quarter, we will use the class time to review each others’ code. The next few classes will be lectures on technical topics, and then the rest of the classes will be codewalks in which one team presents their implementation of the last week’s assignment to the class. It will be the job of everyone else to think about the code, ask questions to understand it, identify possible problems, and suggest improvements. A group of panelists will moderate the code walk and discussion, making sure it stays on topic, constructive, and compiling the feedback for the presenting team.