AltiBiz is not yet fully represented on our website, but rest assured this is coming soon. We’re working closely with our clients to satisfy their business requirements, which has been a tremendous learning process. AltiBiz has successfully implemented their business processes, overcome technical hurdles and adapted to meet HELB’s requirements, cost effectively and without the pain of traditional custom software development we hear about too often. To learn about how AltiBiz can improve your project management and business processes please get in touch for a free no obligation discussion, either in person or over the telephone.

The stack
The fact of the matter is, when we were deciding on a technology stack, we went with what was SURE to work, and that’s a desktop application, using some controls and utilities we already had at hand. Looking back, the best decision we made. Web is fine and cool, but honestly, there are some hard questions you STILL have to answer to your client when you develop web applications, especially if you want to avoid word “sandbox” and “browser” as an excuse. The other thing that’s bugging me with web is that constant feeling of a catch-up with latest and greatest. And even the latest and greatest in web, in UX terms, is just playing catch-up to what we had around for the last 20 years – native. And you’re playing catch up with a kid’s shovel (js, immature and constantly changing frameworks) compared to an excavator (c#, tried and tested libraries and controls). Not to mention that native is an option again, so after being terribly outdated and old-fashioned, we are suddenly cool and an acceptable solution. And hey, you have your own little app store with a blazing fast install and automatic updates (ClickOnce). You just slap a nice metro skin on it and you’re all the rage!

The build
Then we started building it, but the first few (hundred) iterations were going very specific, very one-client oriented, struggling with deadlines and (bad) initial decisions. We wanted to ship fast, compromises had to be made. But as the application developed, feelings were pretty gloomy. It looked too specific, it looked hacked. We did a lot, but we didn’t see the value in it. Constantly changing requirements didn’t help either.
I saw more than few projects die in a long slow death this way. Choose the stack, choose the tech, set them in stone and build on that. Do it fast, whatever, just don’t mess up previous work. But honestly, it was the right way to do it.

Few years later, it looked pretty grim. There was all sorts of loose ends, weird solutions, redundant properties and logic. It worked, it was even manageable, but it felt bad. I felt bad, i didn’t imagine it like that. I started thinking what should be done, and came to a few conclusions:

1. Be brutal about naming – You don’t feel like the name of the property really reflects the usage, or the usage changed? Change it, now! Even if it’s in database, in some off templates and magic strings.
2. Be brutal about DRY (Don’t repeat yourself) – This is pretty self explanatory, but i just wanted to add that i haven’t seen any cases where it couldn’t be implemented. Even when it’s a small change in the middle of the code, you can refactor that part into function and hand it over as an argument to that function.
3. Remove magic behaviors – A client will often come to you and say “Hey, i would like to when I add a user to system, that every user is automatically added to resource planning with a custom resource type, but I want the system to intelligently decide on that” or something similar. The alternative, manual work, is few more clicks. Users are added rarely, so this kind of thing should be a no go. Or you have to make it very obvious that something’s going to happen. Always try to provide an option, instead of mandatory procedure. Behaviours should be universally expected.
4. Remove magic and too specific buttons – Always ask yourself, could this function be handled with a simple copy and paste function, instead of a button which does some magic with order items.
5. Rewrite critical parts if they feel cumbersome – If you’ve invested more than 6 months in that application, it’s going to stick around. You will not get rid of it so easily, and you’ll be looking at that mess forever. But be incremental about it and explain it to your client. Make 2 versions of classes and exchange them gradually. Use [Obsolete] attribute. Think about how to make it better. Think about how some classes could be merged into one, and others split in 2. If you can’t decide on which of the 2 Grid classes to use, and don’t have the slightest idea about differences between them, you have a problem.

The goal
The ultimate goal? Reducing cognitive load to minimum. You have to be able to recognize, instead of being able to remember. If you don’t recognize WHY that’s there, you have a problem in front of you. When every part of your code is there because it is a perfect, unique snowflake in your snowman, you’re in the right direction. And you’ll feel good about it.

But the added bonus of this refactoring is that you also reduce cognitive load on your users. They have to know less, handle less quirks, remember less buttons, and use just a few very powerful and universal tools and functions while navigating your app. Think about that. What powerful and useful functions could span through the whole application. In the end, that’s why excel is so popular:).