Cendyne.dev Posts

Approaching projects - Part 4 - 2021-11-09

Do you have a project, a skill, a goal you'd like to complete or progress? Are you on your own, lacking leadership and structure, or could use more of it for yourself and your team? Here's what I've discovered works for me as a solo software developer and later as an engineering manager. This is a series of posts, the next post part 5 on modelling a plan comes next.

In the last post Approaching projects - Part 3, I described how to define milestones that build confidence in delivering a project. This post will focus on preparing for an actionable plan.

Throughout this series of posts I will be using this user story: As a person with money, I want a custom computer desk to fit in a weird spot in my home. With the chosen solution: Build the desk myself.

Final preparations for a plan

First, a few preconditions for a good plan:

At least, for a low risk project. So let's qualify that, what makes a project risky?

Not understanding the story / problem presents the most risk. Even when the client is yourself, take the time to understand the story. What needs to be solved?

To replace programmers with robots, clients will have to accurate describe what they want. We're safe.

Another: not having a model.

vibrating
Flying to the moon for the first time must have been the hardest challenge.
When you lack a model, you need to research and develop prototypes. These don't have to be complex or involved, merely prototypes prove an approach that works at a small scale with the expectation that it can scale to something larger. Also prototypes can build upon one another. Consider the space example! To send people to the moon and back they first have to get something living out in space and later verify it can return. Scaling this up to a human took more prototypes. Separately the idea of getting to the moon and back was another line of prototypes, both assembled (in concept) at the end to achieve the deliverable.

Without understanding your resources and how they will be used, your project will not succeed. Consider intangible resources too. I would never build a desk if I lacked power tools. I don't have the training or experience to use traditional tools, nor the physical capacity to use them. Yeah, I have a hand saw, no I would not use a hand saw for everything.

Understanding the story

There's lots of material out there on designing solutions for big problems. I won't be writing one any time soon, but I'll provide my tips on this below. But if you do start looking for material, maybe try Rework by Jason Fried.

Lots of books about designing solutions

When you get a story like Cendyne wants a desk with a weird shape, see if there's a proposed solution already. Here, a desk is the requested solution.

But why a desk?
For a computer.
laptop
Why a computer there?
It has access to sun light which is important for my mood, it is not next to the bed so I think it will feel less cramped. I also want to separate my personal space from where I do work.
access-granted
Where do you do work?
In a walk-in closet.
ssssh
Where else could your personal computer go?
The only other options are.. A laundry room, the kitchen, the living room, and the basement.
think
What else could go in this spot?
Nothing useful, a cabinet or a dog bed.
shrug
Do you have a dog?
No.
bet

This conversation is important. The stakeholder may have already explored a few options. They see it as important enough to have requested something be done. If the story was Cendyne wants to use a space in his home effectively then the conversation may begin with a discovery of what effective use of a space means to the stakeholder.

Ultimately, the objective is to effectively use a space in this home for a personal computer.

Continue to converse to find out some key acceptance criteria and what the deliverables are.

Ask about the space the table is to fill, the needs of a personal computer on it. Then dive into what a table is (since that is the deliverable). Take the time to research not only how a table is generally constructed but what makes a table worth the resource cost.

Remember, the table project is an example. This process applies to software too! Take for example a newsletter subscription. Sure, there's an entire market for literally newsletter subscriptions. Maybe your solution will be to integrate with those services. But... if you do end up having to build your own (in this case, don't), rejoice! You have a lot of examples you can reference.
blep
peeking-from-door
There's a lot that goes into a proper newsletter. First, you need to track who is enrolled, and to what filtering channels, subjects, tags, whatnot, this should include enrolling. Second, you need an unsubscribe link. Third, you'll want an interface to submit newsletter publications, this interface may need filters options so that a subset of the audience is to be notified. And Fourth, you'll need a way to queue and send out all notifications.
Something like this is already on my mind professionally. The company lawyer wants to blast out (big number) of emails for a privacy policy update. This is technically a transactional email and not a marketing email. So after our last one, (big company here bought by another big company for 12 billion) cut us off for this use. Like many new projects, it comes to me for recommendations.
tail

So after exploring what a good computer desk is like in concept and finding out the physical requirements for both the table and what physically makes a good table the requirements are:

  1. A large flat level surface being 26 inches deep, 72 inches wide and suspended about 30 inches from the floor. Additionally:
    1. It should be sealed so that it does not get warped by moisture
    2. It should be beveled along the edges so that it does not cut at the wrists
    3. It should look nice
  2. Space to add monitor arm mounts with clamps 4 to 5 inches in depth.
  3. No support beam bars on the very front below the surface
  4. Any support structures should be easy to forget

In Part 2, Discovery and Feasibility, I mentioned that my feasibility research determined that I'd need a jointer and planks to join.

However upon review of the requirements, how would I make beveled edges? On my night stand, I actually used the cheap hand sander to smooth the pine edges. This would not be effective for hard wood. While I have a jig saw, it would be wholly inappropriate and unsafe to try to do beveled surfaces by hand along the desk. Therefore I also needed a router with the appropriate bit to do beveled edges.

The last requirement for the table surface was to make it nice to look at, not too distracting, and last a long time. Also not splinter! I considered paint like the night stand, but disliked the drab look of it. An alternative was to stain or have it be naturally colored. So I opted for wood staining and a clear coat finish.

Models for deliverables

The primary model I referenced was the night stand.

Completed night stand

As part of my night stand experience, I saw that I easily made indents by tossing a tool on top one time. That experience made me conclude that the wood type was not appropriate for a desk surface.

But what kind of planks do I need? This goes back to what makes a good table. Pine (a species of tree) makes soft wood. A good desk should not indent or scratch easily, hard wood must be the answer. While searching for options at the hardware store, the cheapest hard wood I could find was red oak.

wink
Remember to reflect on the properties of a model. You may find that adjustments are needed for your current project. Each adjustment should consider what options are available and why those options are favored over the model's chosen materials / pieces / components.

Another factor: appearance and sealing. I could have painted the wood like the night stand, but determined that red wood's grain was appealing and worth retaining. The color of the grain was not to my aesthetics however. So I performed additional research at this point. I learned about wood staining, but I did not have a model for it. In this case, I used the underside of the table as a prototype for staining wood.

As I experimented on the underside of the table (after jointing), I learned how many applications were necessary, how the sun affected its drying and bonding, how to clean off the excess stain, and so on.

I also learned that it is important to test compatibility between things. Pine wood is terrible with wood stain. It comes out splotchy and absorbs too much in some areas and too little in others. The legs of this table (which are pine 2x4's) were to be stained. After staining with the darkest stain I could find I was so thoroughly dissatisfied with it that I painted it over with black. This was a set back that affected how much time I put into this project. Those happen too.

A software analogy! I proved that one of my methods worked well with a helper class and replacing some parts in a JSP. It's in use today and has enabled a new type of business to launch. But then when implementing it with HandlerMapping I found out that Spring Boot bundles the resource mappings with the error handler. While the idea extended safely, the compatibility of it came with unfortunate caveats.
bullshit

Next: I used Minwax Polycrilic clear gloss finish. It worked but I found on my model that it would easily form congealed droplets and cure with a cloudy bump. What I learned here is that as I apply it to the main surface, I must do so in several thin applications, waiting for it to cure before applying the next layer.

Resource allocation

So when it comes to resources, think about everything. Not just money, but also involved patience, effort, time, and room for mistakes.

dying-at-computer
Not every project goes smoothly. Not every resource got accounted for. For example, I did not consider that the temperature of night time would affect cure times. This took more of my time when I had time because of a process outside of my control. I needed different types of brushes. I needed more clear coat. The list went on for this project.
There were times where I physically could not continue. I wore my shoulders out, my wrists, and so on. The muscles needed for this activity are not innate. Projects like this reminded me of physical signs of exhaustion that I must heed. In fact, I strained my back in another wood working project so badly that I took six weeks off from nearly anything physical due to pain. The fix was not to rest more, but to do some proper stretches for the affected muscles and to walk each day.
exhausted

So gather the tangible and intangible resources needed for your project. My true list had dimensions and quantity involved, but that was over a year ago. Here's an estimation of what I had to find or acquire or make.

Tangible:

The list goes on.

Intangible:

Router goof up

If you are using parts of your final deliverable as a prototype to acquire experience, make sure you're operating on an area that won't be visible or used. I accidentally tested the router on the wrong side of the table surface.

Once you understand your project's needs, what resources will be used, and confidence in the solution you'll go with down to each deliverable then you can make itemized achievable steps. At this point, you might be able to give a good estimate on how much time will go into it too.

The main takeaways of this post are:


This post is the forth of the series, part 5 on modelling a plan comes next.

excited
You can succeed! Take the time to explore and vet the approach before assembling it all together. Account for resources, keep in mind that resources are chronically underestimated. Find out the limits of your approach early on.