CST438 - Week 1

CST438: Software Engineering – Week 1

What did you expect a course in Software Engineering would cover?

I expected that the Software Engineering course would include programming assignments and strategies for executing large-scale projects in group settings, similar to what we did in the CST338 Software Design course.

After completing Week 1, how has your opinion changed?

No, my opinion has not changed, since Week 1 did include a programming assignment. The only difference was reading Chapter 1 of Software Engineering at Google, which highlighted the differences between programming and software engineering discussed below in my journal.

In the first week of the software engineering class, we explored the use of REST with the Spring server. We modified the application properties to create two tables for customer and order, where customer_id and order_id are sequence-defined. The entity classes are annotated with '@Entity', and the customerId variable is mapped to the database cust_id using the '@Column' annotation and the '@GeneratedValue' annotation. Similarly, we defined an entity order class and joined the order to customers using cust_id as a foreign key from the database. The same was done for the customer class to establish a bi-directional relationship adding '@oneToMany' in this case. Repositories were also created for each Java class as an extension of the CrudRepository.

For the controller classes, we used '@RestController' to return values in JSON format for client requests. Customer registration is handled by the '@PostMapping' annotation to send the information defined in the CustomerDTO to be saved in the CustomerRepository. Orders are created by passing customerId, and requests are updated in OrderDTO. Additionally, we retrieve order history using the '@GetMapping' annotation as a stream and map it back to a list. At the end of the lab, we reviewed data validation by adding the following annotations along with messages: '@Pattern', '@NotNull', '@Size' constraints. 

We reviewed the Spring Boot test environment, WebTestClient, with JUnit for unit testing in Lab 2 to verify the creation of the correct record for registered customers and order records. The idea was to create the first order with orderId equal to zero and check its existence. We then made a second order to check that its orderId was not equal to zero since that was reserved for the first order. The final portion of the lab tested the validation method. We utilized the built-in registration method and order creation to verify bad requests based on the provided data. JsonPath is used to query the JSON values for received messages and match them for validation. The building of unit tests should follow the FIRST principles: Fast, Independent, Repeatable, Self-checking, and Timely.

Chapter 1 in Software Engineering at Google introduces the concept of software engineering practice and how it differs from programming. The author reviews three main differences in detail: time, scale, and trade-offs. The software engineering leader manages scalability and balances trade-offs to produce sustainable products that can withstand changes over time. For instance, the development of software planned for longevity must include upgrade plans to avoid the challenges and costs of future overhauls. Delayed upgrades pose a significant risk compared to incremental ones over the years and may incur additional costs to extend the product lifespan.

Hyrum’s Law highlights the concept of entropy in software development. As the Law suggests, if many end-users start to rely on the software we develop, they will likely use it outside of its intended scope. In other words, user’s behavior complicates the situation and the changes we make to the software may break these unofficial features. The lesson we learn from Hyrum’s Law is that changes must be planned and communicated to users. Additionally, a feedback channel between the developers and the users should exist to prepare for any complications. Takeaway: products intended for long-term use must aim for sustainability and invest in integrating transitioning capabilities.

The scaling of resources presents an interesting balance and a complex question to answer. Long-term code requires additional labor to cope with entropy and its induced complexity over time. The variety of costs related to scaling is not limited to human resources but also involves computing power, logistics, and careful coordination. Therefore, the lifecycle of software maintenance forces organizations to maintain scalable resources in different directions. The author of the book points out policies that do not scale well, such as creating more work per person. Instead, policies must be scalable with efficiency and accountability in mind. A good approach is to develop expert-level knowledge among many engineers rather than relying on a few inexperienced engineers to solve problems. It is also beneficial to identify issues in the early stages of development, design, and coding to prevent costly fixes and delays.

The management of trade-offs and costs matters beyond the cost associated with money. It is essential to foster a culture of decision-making grounded in clear reasoning and avoid relying on single-handed direction. The chapter was a great introduction that helped me understand the boundaries and differences between software engineering and coding. As the author emphasizes, software engineering is about the set of policies and procedures that a team needs to produce usable code over time.