Sailware

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 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 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?"

"Short lists get done; long lists don't." I have been applying this to my side projects and tasks around the house. It's been helping me get stuff done. I got more crumpled-up completed short lists than long lists.

More gets done when I work with short lists. I spend less time thinking about the overall process and the ideal path to get there. Instead, I pick the next three tasks that would be most beneficial for reaching the conceptual end. When it comes to software or regular chores, there never really seems to be an end. It's always a conceptual end. There is always some type of cleaning, maintenance, or upgrade that always seems to show up when you think you have done it all.

Instead of drafting out the long grocery lists of todos. Grab a post-it note and write down the next three most important tasks that will make the next big difference. If one of those tasks is too vague and is really an everything task. Break that down into smaller tasks. Limit yourself to less than five tasks. Only the important ones will be written down, and anything else will follow on to the next short list. If it doesn't, it probably isn't important.

Go make your lists and get stuff done. You will be surprised at how quickly you accomplish your tasks and how much progress you will make. The iterations over the lists might just take you on unexplored paths to your project's conceptual end.

A former colleague of mine referred me to the book A Philosophy of Software Design. These are some of my thoughts, as I enjoy reading this book.

The first chapter discusses the concept of complexity and describes it as such: "Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system." I think this is a good description of complexity in relation to software, as it does not focus on a specific part of a software system. The author continues by also mentioning that complex software systems are hard to understand and modify, while simple software systems are easy to understand and modify.

Complex software can come in different forms and sizes. A small section of code can be complex, or a large software system could be simple. I personally have come across platforms where the idea of the software itself is complex.

When designing and building software, it is our job to understand that it is in our best interest to build simple software for ourselves and the future maintainers of the software. Everyone will be thankful for that foresight.