Approaching projects - Part 1

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, part 2 on discovery and feasibility comes next.

What are you working with?

First it is important to classify what you're doing. Are you developing a skill to be used again later? Do you have a deliverable in mind? Is it a product to be used by someone else? What kind of lifetime will it have?

These questions apply to more than just delivering software. Here's some real examples I've gone through, start with a user story.

As a person with money, I want a custom computer desk to fit in a weird spot in my home.

While chasing to satisfy one story, more may spawn.

As a hobbyist wood worker, I want more outlets in my garage so I can avoid extension cables which I tripped on.

Consider these as later projects and avoid recursing into solving rough edges. Don't be the engineer who gets distracted fixing nested dependencies. This is different from shifting priorities because of a bigger problem.

Vincent Verschuren

For your privacy, this youtube video was not automatically loaded.
Click this area to load an embedded youtube video.

Hal fixing a light bulb (from Malcolm in the Middle S03E06 - Health Scare) Monday, Jan 9, 2023

But let's get back to the the custom computer desk. This is a physical deliverable for myself with a long lifetime.

This is a high order, one that I immediately recognized that I could not accomplish with my skillset.

So the desk story could have been solved in a few ways.

• Commission a custom desk from somewhere
• Build the desk myself
• Use the weird spot for a different purpose

There's several parallels here in the software business, likely others too.

• Do you go with a Software-as-a-Service to solve the problem?
• Do you aquire a technology from a company or buy the whole company?
• Do you outsource it to a contractor but own the technology?
• Do you invest in your own team to build the technology?
• Do you prioritize other things and shelve the problem?

Anyway, I chose to build the desk myself, this forced me to invest in my own skillset to satisfy the story. Thus an acceptable but blocking user story is born:

As an unskilled person, I need to gain the skills to build an acceptable table.

This is an intangible deliverable for myself with a long lifetime.

Intangible deliverables are different. How is such a thing delivered, considered done, accepted and satisfied? Think back to school, public education, whatever you went through. You took tests. Each test is a tangible deliverable.

I really did not like standard tests, especially what became common core and ACT tests. Each test left my hands shiny on the Proximal Interphalangeal Joint (the first joint beyond the knuckle along the fingers) because they'd grind from all the shifting and tight pencil holding. But now where I am in life I understand the tests and the need for it.

So let's consider, what are tests for? In my eyes, tests are a controlled simulation of a later and greater tangible deliverable. That's a bit wordy, let's think of an example. The greater tangible deliverable is a computer desk. What properties does a computer desk have? It's got dimensions friendly for a screen, keyboard, mouse, speakers, cups, and snake figurines. Lots of things. What about a useful prototype? It needs to be a level surface that things can be put on at an accessible height. Now what's a useful object that matches this abstract description? A night stand!

With a tangible test in mind for developing a skillset to make a computer desk, we now have another user story:

As a person learning a skill, I need to make a night stand which is considered disposable

Disposable? That's right, a learning prototype isn't production worthy, and that's okay. This expectation must be clear before and after completion. The night stand I made looks okay, but I may not keep it if I move.

This is a physical deliverable for myself with a short lifetime.

Further, this test was a milestone for an intangible deliverable. In a way it was like but not exactly a milestone for the tangible deliverable of making a computer desk. However because it does not directly contribute to tangibly delivering the computer desk, it can only be used to assert confidence in the dependent story of making the computer desk.

Here's the takeaways from what I described above:

• Projects can depend on other projects. To a stakeholder, nested projects may be an instrument to gauge confidence on the delivery of the primary project.
• Projects with the goal to develop a skill should be considered an investment. To measure the progress of that project, tests should be performed with tangible results.
• The deliverable may be intangible, include tangible tests to verify satisfaction.
• Consider the lifetime of a product's deliverable. Short term deliverables exist to set up confidence in long term deliverables.
• Identity project scope, resist scope creep, and prioritize satisfying the primary project.

Ever thought about what unit tests are? Here's what I think. Unit tests are tangible deliverables with a short life time (they do get rewritten occasionally, after all) which gauge satisfaction of a feature, regression, or a story in general.

Another thought! Unit tests allow a developer to prototype and gauge satisfaction of an idea prior to committing to a larger and more thorough implementation. While unit tests are probably a preferred way to verify an idea, I usually end up doing it in a quick .jsp (java) or with some node.js.

Bonus take away! Prototypes may not be production ready, but they can still be useful. I can go back and look at what I did on this tangible desk and remember what I did to solve which problems. It is a model that I can reverse engineer and treat as a mnemonic to remember the concepts applied to produce a useful tangible tool. Don't throw out your prototypes, reference and learn from them. Use them to teach your peers and reports about what you learned. It's easier to digest concepts with smaller scopes.

This post is the first of the series, part 2 on discovery and feasibility comes next.

You can succeed! Delivering a project is possible so long as you stay within your means, balance risks and rewards, address risks and stay grounded to reality. Being honest with yourself and truly understanding the story and its solution is key to success.