Software is quickly born, but is slowly grown. Knowing how to raise software properly ensures continued return of investment, and prevents costly rewrites that can bankrupt you.

Philosophy

Software happiness is…

Software happiness is the ability for an app to reach its full potential and maintain that state for years, ideally forever. It is its ability to remain agile in the short-term, as well as the long. And it is its ability to do this through the change of various hands of professionals over time.

Why software happiness matters

Businesses often build or sell software that becomes critical to their survival. But far too they become neglected and unmaintainable, sometimes to the point of requiring rewrite or in some extreme cases closing of the business.

Principals

Love

This is by far, the most important thing happy software needs, and lack of it is the leading cause of app health issues. Software that is not groomed and looked after regularly becomes black box or obese (usually both). Software needs someone to sit down with it and refine its inner workings regularly, if it is to remain nimble and agile throughout its years.

Software does not need unbounded amounts of love; But it does need a lot, and chances are good that your software could use more of it. These investments are harder to see the fruits of, and are not sexy. But without them, an app gone bad can take out an entire company.

Mentoring

As an app grows, it will usually acquire different needs and interests. Without guidance, these can cause serious damage to an app over time, and potentially make it too complicated to use. It is important, when designing a particular role or feature, to remain humble and curious. Far too often, people try to play the “my way” card. And while this card does work and has worked, it’s not the right card for most people.

By far, it is better to listen to what others say, and make informed decisions from that. Although this isn’t exclusively true either. Really, the issue isn’t playing the “my way” card, its knowing when to. Sometimes, you will know better. Other times, you won’t. It’s important to know the difference, and change tactics to suite.

Attention

Not adding features to software can be as deadly as adding too many. While it’s certainly possible that your app does not need anything else and has reached a state of “doneness”, chances are good that there are optimizations and tweaks that could be made that would improve the utility of an app. When tastefully done, the resulting improvements can place you at the top.

However, not all changes are welcome. By far, the least popular change to an app is with its design. While sometimes this does improve the app and make it better, far too often changes are made that only serve to confuse or anger users. Which leads us to the next topic…

Listening

It’s important to listen to what people say; the people who use your software, the ones who build it, and the market overall. They will often have valid suggestions or complaints that would be in the apps best interest to discuss. While how you react to their comments is the result of several factors, that you give them forum is the most important part.

actively not listening, has killed or at least effectively killed countless software projects.

Vision

Your well-adjusted software needs a purpose. Without it, it will meander off in different directions and likely not land anywhere useful. If you don’t know what your software does, needs to do or could do, it can’t get anywhere. Sometimes, wandering aimlessly leads to wonderful things; But usually it leads to death. If your software does wander about, it should do so with intent and measurement of performance and tuning. But once you’ve established what it needs to do today, you should think about tomorrow.

Safety

Security is a hard problem, and a hard sell. You could leave your front door unlocked tonight, and it probably wont matter. If you left it unlocked tomorrow night too, it still probably wouldn’t matter. But one night, you’ll leave it unlocked and it will matter. Or, you’ll leave it locked, and it won’t matter because someone broke in through your window.

The moral of the story is: If you do everything you can, you can stop the simple and easy security breaches; But at the same time, there many windows in a house, and you can’t protect them all. If you’re not taking a fort knox style approach to security, you should at least know whats at stake and how to react if something happens; though with software, there is the added need of detecting when something happens in the first place, as there is rarely broken glass found.

Exercise

Keeping your software in shape means exercising all of its parts regularly; both together and in isolation. This ensures your software performs as expected and is free of bugs. And while you can manually sit and exercise your app, it’s usually prefered to write software that tests software; especially under heavy & active development. Writing these is the responsibility of the developers, and it is the responsibility of software parents to make sure it is taking place.

But sometimes exercises are redundant or pointless, and bugs are allowed to creep in. Or other times the test software is so poorly written, that it becomes unreliable or unwieldy. Or, maybe there are no tests written at all. Thankfully, All of these can be addressed using the love and listening principles, previously outlined.

Discipline

It is tempting of creatives to push their boundaries. Artists want bigger paintings, writers bigger stories, actors bigger movies. Developers and Designers are no different in this. Developers want to use new languages, databases or techniques, designers want to create impressive and definitive designs with new frameworks or syntax. And while these can and do lead to some impressive things, they far too often become a disability and a hinderance to the app. Tried and true solutions and approaches are boring, and there is always the temptation for something new. But boring is what makes happy software, so one must strike a balance between the two.

Generally, it’s useful to think of such things as genie wishes: your software only gets 3 total. If you’re going to use a new framework or language, there should be a strong reason for it; one that current tried and true best practices are unable to solve. There are many fads in software, and its important to sort them out from pivotal changes that move through industries.

Mobility

Happy Software has the best chances of reaching maturity and stability when developed by professionals. A professional is more than someone who can do the work; it is someone who can do the work well, and is striving to do better. While the amount of money paid is not a direct correlation to professionalism, it’s certainly a useful metric. You don’t get happy software by being cheap; you get it by investing time and money into its growth.

The professionals who build your software should be improving its maintainability and lowering the bar for other professionals to take over who are less experienced. The people who build buildings are not the same people who sweep the floors after its built, and the same holds true with software. As your software grows and matures, its needs will become more detailed and nuanced. Difficult problems will be solved, laying way for easier problems to be solved. Its important these transitions be able to take place.

Things you can do

Talk with your professionals

Communicate your desires and establish with them how things will look in the next few months to the next several years or longer; both given current course and in an ideal world. Also Identify their involvement and how best to position for any transitions.

Do Nothing

Sometimes inaction is the best action. If things are manageable and the risks are known and understood, sometimes doing nothing is the right call. Software happiness is not a short term solution, but a long term one. However, Software rarely exists in a bubble, and the slightest change to any one of hundreds or thousands of other dependencies can cause a chain reaction of failure that result in loss of revenue, customers, or data.

Hire an advocate

Creating a better future for your software is no easy task, especially if you are not involved in its development. professionals make mistakes, or underperform, and its hard to tell the state of things if you’re not in the industry. So whats the solution? Hire an advocate. Having an unbiased party involved ensures that all priorities are being met appropriately, and that the app is heading in the right direction for its short and long term goals.

Hire Me

I’ll work with you and your professionals to improve the well being of your app and make sure it gets the attention it needs to prosper in the short term and long.

Hourly rate is $225 per hour Weekly rate is $7k per week

email r.hire@ruru.name for more information.