Start slowly to finish fast

“In programming, the hard part isn’t solving problems, but deciding what problems to solve.” – Paul Graham

I am fortunate enough to work with new, genius, competitive developers who have fresh perspectives. They often talk about faster algorithms, data structures, new-generation technologies, and buzzwords in the software industries. They are eager, motivated and wanted to change the world!

However, I did not hear from them about problem-solving using object-oriented analysis and design.

Some people try to solve the problem by directly jumping into programming solution without doing an analysis. They believe in trial and error methods. It’s like solving problems without knowing what problems to solve.

The well-proven OOAD techniques are there for decades, It’s a very beneficial technique for problem-solving. They will help you to know what problems to solve.

We should focus on what problems to solve rather than just writing the code.

IMO, we should start slowly to finish fast. What I mean here is, we have a problem at hand, divide it into three parts: Analysis, Design, and Programming.

These three are related terms.

The object-oriented analysis is meant for understanding the customer problem. Write use cases to capture what is needed and what is not. You can write lightweight use cases. Thus, you’ll focus on what is needed than trial and errors.

Benefits of writing use cases!

The next step would be the object-oriented design which emphasizes on designing the conceptual models i.e. classes to achieve the various use cases.

This classes will have attributes and behaviors. They interact with each other to solve the problem.

Try using outside in approach, class diagrams, sequence diagrams. You could use the whiteboard to evolve your conceptual design that tries to solve the customer problem.

Object-oriented thinking, the big picture!

Then comes the programming phase. Now you know “what part” of the problem and conceptual models, you can focus on how part i.e. coding.

The good analysis and design would help you to understand problems to solve, prepare good conceptual models, that intern leads you to good programming solution for the problem at hand.

Remember, don’t directly start coding without understanding the problem to solve.

Instead, use object-oriented analysis and design.

Start slowly to finish fast.

Object oriented thinking, the big picture

I see my recently graduated friends solves consumer problem by the procedural way (writing everything in a single class or a method) using object-oriented programming language.

In this post, I am sharing what and how I think while solving the consumer problem, The object-oriented thinking!

IMO, as an object-oriented designer, I divide the big problem into smaller ones. I provide the solution for small problems (concerns) using objects. Eventually, these objects communicate with each other by sending messages to solve the consumer’s big problem.

Let me explain it with the help of the use case. (We will consider the server-side solution)

Problem statement:

As the new user of the system, I want to register a user account.

We would consider only two fields on the user registration page, Name, and Email and sign up button.

Use case:

User can create his/her account

  • As a user, I navigate to the registration page.
  • Enter name and email.
  • Choose to register.
  • The user account is created.
  • Email is sent to the recipient.

The user cannot create an account when a name is not provided.

The user cannot create an account when email is not provided.

Solution:

As a developer, I need to provide the solution for these use cases. (I know there could be many alternate cases, however, let’s keep it simple.)

Clearly, there are different concerns that need to be addressed.

IMO, we need a class:

  • To validate the user inputs.
  • To create a record in a database.
  • To generate email content.
  • To send user registration email.

Thus, I would divide the concerns into

  • UserValidator class that validates user inputs and gives an error for validation rules like the name is required, email is required and so on.
  • UserRepository class that takes user entity and insert records into the database.
  • EmailTemplate class that generates the email content.
  • EmailSender class that takes email content and sends the email to the recipients.

UserController class that does the following stuff and try to solve the big problem by sending messages to the object of the above classes.

  • Verify the user inputs.
  • Create a user in the database.
  • Get registration email content.
  • Send registration email.

Note: To convey the intent, I kept this design as simple as possible. We could give more clean solutions like outsourcing the responsibilities of the controller (Keep controllers as thin as possible) to model classes and so on. Please feel free to share your feedback with me.

You can observe, The proper object-oriented design would divide the big problem into the smaller ones across classes. Solve small problems in order to solve the bigger one.

https://blog.beingcraftsman.com/datta/

How writing use cases can help you

During my initial career in software development, I was directly jumping to a programming solution without doing problem analysis.

I still remember sometimes I had missed some of the functionalities since I haven’t done the proper analysis.

I and my product owner were having too many discussions.

When I worked with the education team in Tieto, I got the habit of analyzing customer problems. During analysis, I choose to divide the customer problem i.e. requirements into use cases.

I choose to share it with my product owner before starting the coding. 

Since then I have been writing the use cases before starting the coding, why? See these benefits.

  • You could anticipate whether estimation assigned to a story/work item is correct or not and can raise the flag within the team.
  • You could easily break down the work into the small minimum viable product.
  • You could get better ideas about use flows like instead using a button in grid row, we could use a toggle button.
  • You could create a happy path, unhappy path, edge cases, and alternative flows so that you would not miss any cases or functionalities.
  • You could easily track the progress of the story/work item.
  • You could give clear updates in daily standups as I worked on use case#1 yesterday and today will finish use cases# 2 and 3.
  • You could anticipate the code changes in advance against all cases.
  • You could anticipate the blocking dependencies say for example you’ll need an answer from the product owner.
  • As a developer, it would help you to write tests against these use cases.
  • As developer/QA/PO, you could do functional testing against the use cases.

I would recommend you to go through

Use cases in Wikipedia

Agile Use Cases in Four Steps by Matt Terski

In my humble opinion, try to write very lightweight use cases instead of the very descriptive essay.