Sailware

Your Assumptions Are Probably Wrong

To give this post some back story. For my day job, I work for software companies. Over the years, team members have moved on and new team members have joined. When we talk about the software and perform our software planning tasks, there tends to be a lot of assumptions. This is something I have been noticing over the years.

Assumption: an assuming that something is true


Fact: something that has actual existence

You know what they say when you assume: "You might make an 'ass' out of 'u' and 'me'". When it comes to software planning and assumptions I will say "You are probably wrong". Of course this is contextual to the software and the team working on it. The older the software and the less experience the team, the more assumptions will be incorrect. I have found it is best to avoid assumptions in software planning. When you know something it's fact, but when you don't know, you tend to assume.

A lot of this is the nature of software and it's complexity. The more complex the software, the more it plays a role in the assumptions of how it works, instead of knowing. Complexity could be on the code level which only the programmers have to navigate. Software complexity can be a user level with an overwhelming amount of features bolted into the product. Assumptions grow from complexity and the uncertainty of how it works.

History or a lack of, can also be a source of assumptions. It is easy to blame the past for a reason today. The lack of history can lead to a lot of questions and confusion. What was easy in the past might not be today and vice-versa. Having documented software history is better than having none at all. It's best to not rely on historical metrics for tomorrows goals.

To prevent making assumptions in software planning, we can investigate, test and document. It's easy to make assumptions how the software will work. It may have worked that way in the past or other parts of the software work that way, but those are assumptions. To turn our assumptions to facts, we need to investigate and test. This means we need to read or use the software to prove that our assumed idea is true. Once we have verified our assumptions it will be a good idea to lightly document that understanding.

So when it comes to software planning do not base it off of assumptions. Either bring facts to the planning table or create some tasks to investigate any assumptions. This understanding will improve everyone's knowledge of the software on the team while also keeping plans based on facts. It's no fun for anyone when a project starts and assumptions are wrong and you have to start over.

My Software Development Constraints

My recent personal software projects have two main focuses: building for myself, and having fun. I have other obligations in life which do not allow me to spend all day on my projects. When I focus on these two objectives, it maximizes the joy I get out of coding in my spare time. The added benefit is I get a working product that I can use when I am done. There were some realizations along the way. I got constraints.

• I have a day job that takes up a large part of my day.
• I have a household which I am part of.
• I am a team of one.
• No plans for outside money or funding.
• Not looking for external expenses such as hosting and other services.
• To many interests and ideas.

Since I am building for myself, I am on a relaxed schedule. I still want a working deliverables and not be wasting my own money. Most modern practices software would steer me towards building out big software with many layers. That's hard to do by yourself. My time is limited and I don't have that kind of budget.

After some time and thinking about it. Looking back was a good way for a solution. Desktop applications fit the bill. They are self contained so the code is generally in one spot. They can easily be designed for a single user. They don't require access the internet. The list goes on. But most importantly, it fits into my constraints and allows me to focus on building software for myself and having fun doing it.

With desktop applications, I don't have to rent some dedicated server or setup a computer at home to act as a server. This takes a lot of maintenance and upkeep cost off the table. Less setting up servers and then forgetting; more time designing a solution. This checks the boxes for the constraints to respect the limited time and limited expenses.

As for having to many ideas and interests. Some can be combined with the on going project, while other just get added to a journal I carry around. I try to focuses on one project at a time. I pick the project to work on by the idea that solves my biggest pain points in life.

It's has taken some trail and error to discover my constraints. Once I understood them and applied some thought to it, new alternative paths appeared. I feel like I was able to find some additional joy and fun in my software projects in the process. Find your constraints, embrace them and most importantly, have fun.

Software Forecasting

Software planning is for the short term when you got all the pieces out and ready to assemble the product or complete the objective.

Planning: the act or process of making or carrying out plans

Software forecasting is when you have an idea about what it takes but know there might be some variables or irregularities which will effect the outcome.

Forcasting: to calculate or predict (some future event or condition) usually as a result of study and analysis of available pertinent data

Software is complex and if not maintained, your estimates will reflect this and they will always be forecasts. Depending on the software age which is being worked on and the experience of the worker with the software, there is a high chance, that work may always be a forecasts because of all the variables and irregularities.

This goes for the people side of software too. Lose to many people, the knowledge goes with them. Software planning just got harder without them. If the business pivots or changes priority, the software estimates change with it.

Our estimating practices are bad because it is hard. Estimates are effected by so many forces. It is like forecasting the weather. Weather forecast pleases some and manages to upset others. Same goes for software estimates.

Don't get mad at the person giving the software estimates their just trying to forecast what they know. Embrace that software estimates are not so predictable and boring. Enjoy a little unexpected rain on a summers day.

The Feature Treadmill

The software development of a product which has started seems to rarely end or be complete. Defining software as complete or good enough is hard to do apparently. Complete and good enough usually mean it doesn't need anything thing else to function as intended. A lot of software has rich feature sets but seem to never be done adding new ones to the list. You would assume most paid software now days is done by how functional it is, and how long their feature pages are, but you get new notifications about some new additional feature all the time.

I often wonder how we got on this endless treadmill of features and add-ons. Software teams often use methodologies which move goal posts every few weeks. These goal posts representing some big team deliverable. Over several weeks the team members sprint from one goal post to the other. Usually there is very little downtime between them. It is exhausting and very little time to reflect.

Cloud services have allowed for servers and databases to be continuously expanded with contracts giving big discounts for large uses. The constraint of physical hardware limitations are an old problem and beyond clients imagination of their hardware limitation. It's easy to scale and expand your software to the limits of your imagination and design without being bound by the physical limitations of users computers.

Could it be the subscription model which everyone applies? Does the subscription model cause the feeling of constantly having to deliver "new" or "more" since someone is continuing to pay? Does it feel like you deserve more "new" or "more" since you continue to pay?
In the past, the internet was much slower and software came in a different form. It had different design methodologies, different hardware limitations, and different cost. People had a different expectations. You hoped the product you purchased and would worked and was complete.

It's a small reflection of what I remember versus how I view it now. Change is inevitable and the times are different. Constraints and mentalities have changed with the software. One thing that hasn't changed is the desire for complete software.

The Purpose of Software

The purpose of software is to make peoples lives easier. When we are planning and designing software, we should be doing it with that in mind. The way we build and distribute software has changed and will continue to change. The reason behind why software is created has always been the same. Software make the task at hand easier which makes peoples lives easier.

I feel like this statement is true for good software experiences. There is a whole category of bad software which people are required or made to use. Good software comes in many shapes, sizes and used in different contexts. This makes it difficult to determine what makes software experiences great ones compared to bad ones.

Some notable features I believe good software have are:
- Clear verbiage
- Easy navigation
- Designed for the task at hand
- The feeling of being thought-out

There are many qualities to great software, and more than this small list contains. This list was purposely small. I believe small lists get done. These four bullet points above may lead you to a different path on your software design journey. Just keep looking back at the north star from time to time and ask yourself "Is my software making peoples lives easier?"