The First Step: Design Your Solution

Build a Twitter Analytics App

1 Introduction: Start Here

2 The First Step: Design Your Solution

3 In Which I Rant a Little

4  Design Solution

5 Writing Great Code

6 Writing the Backend Twitter Server

Writing the Code in Small Parts: Part 1, The Basic App

Part 2: Adding a Counter to Exit

Part 3: Adding Language and Retweet Count

Part 4: Organising Our Code

7 Adding the Data to a Database

8 Testing: What and How to Test

8.1 Testing Our Frontend

8.2 Testing Our Backend

9 Displaying our Data using the Flask Webserver

9.1 Introduction to Flask

9.2 Adding templates to our Flask app

9.3 Displaying our Tweets in the Flask Web Server

10 Future Work and Improvements

If you were to ask a new programmer what the first thing you do is when you start a project, they will usually say Start banging on my keyboard! Like a monkey is implied.

Wrong.

Others might say, Aghhh, no. You write tests first.

Wrong again.

Why you must Design First

Design has gotten a lot of bad publicity. Mainly from companies that used the waterfall process. Many companies that claim to use Agile are still influenced by waterfall. In waterfall, you did each step one after the other. So, design, coding, testing, release. Once you were done with design, you never went back. So you made sure you did it in excruciating detail. Hence 500 page design docs that had 50 pages of This page has been left intentionally blank.

When Agile came along, many people said, Woohoo! We are done with design. No more documenting.

Which is a mistake. In Agile, you still follow the whole Design-Code-Test cycle, just you do it in 2-4 week sprints, not 2-4 year cycles. Small sprints means you can come back and fix any problems, with redesign if necessary.

Design doesn’t have to be big thick documents. In fact, no one reads them. As I will repeat again later, the majority, more than 50-60% of your document, must be diagrams. Thick blobs of text put your readers to sleep. Short and sweet diagrams will help put your point across, and make it more likely people will read your document. The text must be just clear up stuff that can’t be extracted from the figure.

So why should you always design first?

1. The Thinking Problem

The hardest part of any creative task is thinking. Thinking slows you down, makes you doubt yourself, leads to stalling and getting stuck in the What do I do next? loop.

Design fixes this, because the thinking part has been extracted to an earlier stage. You make all the major decisions here, so that when you come to coding, all you are doing is following a checklist.

2. No surprises

The important thing about a good design is that it should remove most surprises (not all, unless you are a psychic or Harry Potter) .

So you want to use MySql, but the server only supports a proprietary database. When would you rather find out- at design stage, or after you have 2 million lines of code written?

In the design stage, you try to anticipate any known problem, and try to find fixes for them. So that when you actually start coding, you know 70-80% of what you will expect to happen.

You will still face problems, still struggle, but not because you missed something obvious. Programming is hard enough as it is, without also chopping your own foot off by not thinking through the problem.

3. Hardware / software limitations

You will always have limitations. They may be technical, or human (covered in next point). Maybe you don’t have enough servers, or your servers can’t run the version of software you want. You need to be aware of you limitations. I had a big one that stopped me from using the libraries  I wanted, as you’ll see in my design.

4. Human limitations

How many programmers do you have? What are their areas of expertise?

Since this is a learning project, chances are, it’s just you. What are you strong at? What are your weaknesses?

My weakness was Javascript graphing. I had tried dozens of times to get into it, trying tens of libraries, and always failing. This time, I got it right. But for a risky project, or one with tight deadlines, you’d stick to what you know. This is why you get the 10-years-experience-in-technology-that-is-5-years-old type jobs. The managers are simply trying to reduce their risk, and hire some coding monkeys in the process (sorry, I am ranting. I will stop).

Next Step

You must design this app. Don’t look at the link I shared– it is the final version, borne from many iterative cycles.

Start with this. A client / boss gives you this instruction: “I want a web app that will show me the top tweets on Twitter, plus which languages are most common. I’d like to see this in graphs, if possible.”

Think this isn’t detailed enough? You’d be lucky to get even this much detail out of many clients.

With this in mind, I want you to design your solution. Don’t go too crazy, just use pen and paper. In your design, you must consider:

  • What blocks of code you’ll have
  • What they will talk to (each other? A database?)
  • How data will flow through your app

You must have enough detail so that you can give the document to someone, and they’ll know exactly what to do. Don’t go crazy though. Spend no more than 5-10 minutes.

If you have never done a design before, don’t worry. Try it anyway. I’m throwing you into the deep end for a reason. You learn better when you struggle a little before looking at other people’s solution.

Some of you are thinking, Meh. I won’t bother. How will he know if I’ve done it? If you are thinking like this, you are wasting your time. Just looking at my solution won’t teach you anything. And if you aren’t here to learn, why are you here?

So spend 5-10 minutes now, using a pencil and paper, drawing a rough design of how you think the solution should look like.

There is no right and wrong here, remember our design will evolve anyway, as we know more about our project.

Next: Look at my design.

PS: Interested in leveling up your Python and getting a great job? Check out the Python Apprenticeship Program.

Leave a Reply