This class has been a great one to take right before our capstone since it teaches and has us exercise best practices in software engineering. For example, the planning stage of any software development lifecycle is critical because it involves capturing what the stakeholders want–how to build the right thing and how to build it right. During my time at Qualcomm, I followed a Waterfall approach to my intern project and spent a good two weeks on the planning process. In this class, I was able to actively practice Agile with my group members, which involved a more rapid, but continuously iterative planning (and refining) stage.

Another great skill we exercised in this class is communication. Communication is not only important when it comes to soliciting user stories/requirements, but during the development phase among team members. When working on related parts of a microservice or even in a monolith, it is important to communicate what you are working on since it may affect what another teammate is working on. In addition to this, team members may have ideas for how you can approach a problem you are attempting to solve–but they would have no way of offering help if they never know what you are working on.

While “microservices” has definitely been a big buzz word recently, I had a vague understanding of what they were before this class. Now I understand that it isn’t a “silver bullet” and even new projects should start out as monoliths before the project is well-defined and easy to compartmentalize. While developing our final project with my group members, I definitely recognize that there are some pieces on the “front-end” of our project that could be further extracted out as microservices. For example, the front-end allows us to search for restaurants by utilizing the Bing Maps API and the Zomato API. We also include our own schema to store order details. The ordering system could be extracted out as its own microservices separate from the restaurant lookup system. However, this was not clear until we already had several iterations of a working prototype completed.

I was very excited to use Springboot in this class because it seems to be a popular framework in web development careers. Currently I am interning at a web development firm using primarily PHP and Drupal (though I’m on track to become an API Engineer and currently training on Apigee). However, I am eager to learn more web frameworks to open up even more opportunities in the future. This class pushed me to research Springboot’s documentation and community to learn how to implement things we didn’t cover in the scant four weeks before we began working on our final project. This, too, was an opportunity to exercise real-world skills as no one enters a job as a full expert the entire technology stack.

Finally, by exposing us to a longer term final project that spanned the latter half of the class, I believe I became better at delegating tasks. In most of our classes, we either have individual assignments or a short week-long group project. This puts diligent students in the habit of doing much of the work themselves, especially if there is a tight deadline. However, by giving us a longer span of time to interact and work together, I believe it was easier to involve everyone in the development process.

This week we entered our third and final sprint for our final project. Our main focus this sprint was to ensure that all the pieces worked together. We also decided to fake sessions in a way by storing order data piecemeal into a separate session table until we could create the Customer, Order, and OrderLineItem(s) entities upon order check out.

Rather than storing a new row for each order line item, we decided to store the line items as a JSON string in the session table to parse through when it came time to generate the OrderLineItem entities. This meant that the team mates working on the front end had to figure out how to send the data as a JSON string so that it would work. We did a lot more pair programming this week than in any class, and I think it was great experience.

This week my team and I did our second sprint on our final project. I continued to extend out the needed functionality to save entities to our database. I had to read up on Springboot documentation to learn how to define OneToOne and OneToMany relationships in the entity classes so that entity data was saved to our database correctly. I quickly discovered the importance of TDD (test-driven development) as my tests allowed me to organize functionality before integrating the logic into a controller.
During our third sprint, we will continue testing and focus mainly on front end design — making everything look pretty. We’ll wrap up by creating a demo video of our finished product.

This week we began our group project and started and finished our first sprint. Our project, Food Flight, is an application like Postmates or Doordash that enables a user to order food for delivery from any participating restaurant.

Our application is built around microservices that:

• expose data to restaurants to get order information
• expose data for a delivery person to get order information
• expose data for the user to get order update information

Our team is rotating the Project Manager and Scrum Master roles weekly so that we each get a chance to experience at least one of these (we have a team of four). This week I was PM and led my team in prioritizing and assigning points to stories for the first sprint. I also set up our GitHub repos so that none of us can push directly to the master branch. This is to ensure that we all adhere to code review procedures before anything is merged to our master codebase.

I felt that communication was a little lackluster during our first sprint, which is understandable since we’re in a global pandemic and everyone undoubtedly has things going on. But I hope that now that we have an established codebase, communication will be a bit better moving forward.

When talking about requirements, SMART refers to the following qualities:

• Specific
• Measurable
• Achievable
• Relevant
• Timeboxed

Specific

Specific requirements are ones that pair a vague feature (e.g. The user can search for a movie) with a specific qualifier (e.g. by its title).

Measurable

Making a requirement measurable ensures that it is testable. For instance, we may have a requirement that an end-to-end response time for a feature should be less than 3 seconds.

Achievable

Achievable requirements are those that can be completed in a single sprint or iteration. Larger requirements can be made achievable by breaking them into smaller components.

Relevant

A requirement is relevant when it has business value to stakeholders. In order to drill down to what is most important for stakeholders, asking the “Five Whys” is key.

Timeboxed

Development on a requirement is timeboxed–all work stops at the end of the sprint. If the requirement was unachievable, the remaining work can be rescheduled as a new story. If necessary, the requirement can be further broken down into smaller requirements that are attainable. It is also possible to scrap the requirement.

Crafting good requirements or user stories means adhering to these SMART guidelines.

FIRST properties refer to the software testing properties:

• First
• Isolated/dependent
• Repeatable
• Self-validating
• Thorough/Timely

Fast

This is the idea that we want a quick feedback loop. If our tests aren’t fast, we won’t want to run them often. If we don’t run tests often, it becomes harder to isolate problems since we may have introduced several new additions to our code since we last ran our tests.

Isolated and Dependent

Tests should only invoke the method under testing. Other functionality should be stubbed out and asserted. By building the necessary state for your test case, it becomes easier to understand the situation that your test case describes.

Repeatable

Tests should have deterministic results. If test results are highly variable, then they are not reliable. The results of tests should not be affected by the order in which they are called or how many times they are run.

Self-Validating

This is the concept that tests should be able to automatically resolve whether a test has passed or failed. We shouldn’t have to manually inspect the results to determine a pass/fail.

Thorough/Timely

A test suite should do a thorough enough job in covering test cases in order to be confident enough to push the code to production.

Through test-driven development (TDD), writing test cases first can aid in making testing itself timely (i.e. when you need them!) If you let your test cases guide your implementation, you repeatedly test until you meet the expected functionality/behavior.

Additional Resource: https://hackernoon.com/test-f-i-r-s-t-65e42f3adc17

Test Driven Development (TDD) is about developing tests for your application’s functionality before actually writing any code. In this way, your tests guide how you approach implementation.

A mock is a way of stubbing functions/methods that you may or may not have developed yet and providing mock data and results for those functions. In this way, you are able to isolate testing on one defined function that depends on those stubbed out functions. This way, you can isolate any problem to the function you are testing without worrying about implementing those other functions OR (if those functions are already implemented) errors introduced from those other functions.

Before starting this course, much of my understanding about software engineering came from my summer internship with Qualcomm and my current internship at Achieve Internet. Software engineering is a way of applying engineering principles to software development in order to maximize software’s business value. There are several methods of doing this, as our text explains.

During my time at Qualcomm, I helped manage a product being developed by a business intelligence team in Hyderabad, India. We used Agile to develop product stories that would result in incremental prototypes.

But I also gained exposure to the Waterfall software development cycle while at Qualcomm in developing my own project — a RESTful web API. My mentor and I chose this development cycle so I could a) be exposed to multiple software development lifecycle methods and b) be able to take a good 6-8 weeks to scope out my project and develop a first working prototype (this choice was due to the length of my internship).

Since I’ve started interning at Achieve Internet, I have also been exposed to the Spiral development model and how the various people at Achieve (Project Manager, DevOps engineer, developers, etc) play a role at different points of this model.

While my definition of software engineering hasn’t changed since reading the text, I appreciate the solidification and verification of my existing knowledge and experience. I am looking forward to this class!