Low Level Design Part 3: Estimates

You should include your task breakdown and estimates in the low level design in the appendix if it's available.

Design your project with the idea of disambiguating hard questions in mind. Frontload as much ambiguity in the project as possible. Changes in estimates months in advance are preferable to ones right before the deadline universally. Usually, the best way to do this is to write a thin vertical of your project first and then start fleshing out the functionality after that.

If you haven't worked with a library, platform, language, etc. your estimates on that topic will have low accuracy due to unknowns. You can reduce this effect with additional reading, especially of code, or by writing code using that library yourself. Call out everything that you don't know. Low accuracy estimates almost always take more time to complete rather than less. If you estimate a task as a week, the shortest it can be is an hour. The longest it can be is infinity. This asymmetry means estimates are usually close to the upper limit for how quickly something can be done.

Your estimates may appear unintuitive sometimes. It's likely that your gut feeling about an estimate comes from something. Explore that feeling and find the reasons why you think that task might take longer than it would seem. Incorporate this into the task description so it's intuitive. It's usually the case that a highly simplified explanation of project tasks will not include the relevant details that say why it takes as long as you think it is. It's very, very important to include these details.
    Per the Mythical Man Month,every engineer has a base startup cost of reading documentation on the project and becoming familiar with it. If an engineer is only on the project for a single task, make sure they need to learn as little as possible about the project itself to complete their task by giving them interfaces, clear requirements and boxing their component. Be aware of how many engineers are on the project, how many libraries, platforms, etc. each will need to learn. Learning will take a considerable amount of time. For a single task, it will almost always take longer than implementation. Each additional person added to a project increases its communication-based costs.

    Make sure to include features you would often take for granted if you are estimating a new project. If you are unsure, ask another engineer to check. Some examples for a service include: Auth, HTTPS/End to End TLS, Pipeline infrastructure, Monitors, Alarms, Logging, Dependency set up time, etc.

    The most accurate estimation mechanism is comparison to previous projects. Find a previous project that has similarities for yours and see how long it took for each component. This will be helpful in estimating using real world data. This is especially value if this part of the project has high uncertainty.

    Comments

    1. AnonymousDecember 1, 2022 at 10:31 PM

      You can play on-line roulette for actual money in a rising variety of US states. Making a deposit is straightforward, and you'll choose from a variety of safe banking options. Technically, no technique is ever place to} assure you success 100% of the time, 카지노 and any good roulette information will tell you this. See, roulette play on-line may be very completely different from it being live and actual.

      ReplyDelete

    Post a Comment

    Popular posts from this blog

    Using Kanban Boards to Stay Organized and to Stay Motivated

    I often work with Trello or Notion as Kanban boards. I maintain tasks for everything that I do. This helps me keep organized when I'm working on a large number of tasks, or especially if I have ideas for tasks that I am not actively working on. It creates a clear, constant document of the state of the tasks I'm working on. And more than anything, it shows to me what I've accomplished and lives on as a constant motivator for me. Why Kanban Boards Matter for You and Your Team One best practice that anyone working on a large project should adopt is to have at least one Kanban board task they're working on at any given time. Kanban boards are a visual way to track progress on tasks, enabling you to see the status of each task and its associated details. By consistently updating your tasks on a Kanban board, you'll reap several benefits: Greater personal efficiency : As you wrap up your day or put a project on hold, having detailed information on your Kanban board task h...
    Read more

    Importance over Immediacy

    When should I complete this task? This is a question you'll need to answer again and again. Usually, the answer takes one of four forms: early, late, paradoxical and time invariant. The last two being far more interesting and the primary discussion of this entry. Early First, we go through early tasks. Early tasks are ones with reasons to complete them immediately. Usually either output ambiguity or a benefit that occurs continuously after the task is completed. For example, if you buy a phone case sooner, you can avoid risking dropping your phone on the pavement and having to get it fixed. If you have a project with coworkers that depend on you, it benefits them, and you, for you to finish sooner. If you need to apply for a passport before a vacation, it's usually wise to do so months in advance because the patent office is often ambiguous with how long the process will take. Late Second, late tasks. These are usually that involve some kind of input ambiguity or can harm you i...
    Read more

    Low Level Design Part 1: Reading and Gathering Information

    Start out your document writing day 1 with a long list of open questions. As you read documents, you should slowly grow a longer and longer list of open questions. Maintain this list and keep adding to it while you write the doc. Questions are often more important than answers as they represent unknowns you need to disambiguate. You will need to ask people for most of your open questions. This is okay and most engineers are very happy to answer such questions. In general, people will feel more complimented rather than inconvenienced when their expertise is requested. If you can't find an answer to something and don't know who to ask, ask your manager or a senior engineer on your team. What if no one knows in your team? Formulate your question into something brief and meaningful and post it in your org or company-wide chat. If your question is technical, ask it as a stack overflow question and link it in the chat along with your question. Link to everything as hyperlinks in the ...
    Read more