A word for those bad applications : let them live

May 222012
 

TL;DR

Before rewriting even an obviously badly written application, be sure that a) you’ll do it better (this time), b) there is a real ROI to do it and c) it is the best usage of your time.

You know them, I know them

Those applications are all too frequent to be missed. You stumble upon one or two at each company that you arrive, whether as a user (as a developer, it is difficult to not “snoop inside”, even when we know it would be bad) or (worse), as a maintainer. The most typical case is for me custom-made internal applications that probably solved a very simple problem once, a long time ago. They may have been a smart replacement for an Excel sheet becoming unusable (“oh, let me just one day, I could make something far better than that”).

An example

This is not exactly one single application, more like a combination of some that I had the bad idea to find on my way, and that summarize for me the “bad application” case. This application is a web face-on-database, and was initially developed to solve a problem in a single service, which happens to be a part of IT. One of the reasons those things tend to appear in IT services is that those guys have (for better and for worse) the capacity to develop them themselves. If you are another service in a large company, the cost of the formal development demand would probably kill those infant-application long before the first line of code – which is sometime a very good thing.

Over the years, it did grow a bit, adding some features, and started to be used outside of the initial group. In the same time, following the organization changes, it did pass by half a dozen different hands, the initial sponsors (and developers) being long gone to other departments or companies.

Of course, you are not specially aware of all this history when you find yourself the brand new maintainer. What you will spot however is the technical nightmare. Among others, expect:

  • Outdated documentation – if any

  • Creative database engine (MS Access?)

  • Inconsistency all over the place (case, foreign key naming, plural usage, etc.)

  • Large unused parts (but which ones?)

  • A lots of web page with embedded SQL, and not a single line of reuse/import/include

  • Usage of very low level API (cookies, string manipulation)

At this point, it is just screaming “Rewrite !”, and your first report on the application shows a list of problems, and the benefits of rewriting it from scratch as soon as possible. Added bonus: it does not look so complicated, so it would probably not even cost much time.

Not so fast

I’ve been through there, you probably have too. The problem here is that technical debt, while being something too often underestimated, is not by itself an argument for rewriting an application from scratch. The two good questions, once the initial appraisal is done, are:

Will the new solution be much better ?

Maybe you think “Of course it will! We know exactly what it needs to do, and by starting over, we can have clean design allowing for evolution!”. You may be right, but you may also just have started a costly rewrite that could give birth to yet another bloated application. Doing better the second time is possible, but it is far from being automatic. In most situations, it will depends on the sheer size of the application (rewriting big applications is not easier than writing them – actually, as they are already running, it may be harder) and the availability of good information on what it is supposed to do (you do not want to rewrite based on the use cases that are in the code, and it is probably hard to read anyway).

The big rewrite scenario typically means choosing between rewriting the whole application before doing a “big bang” replacement or do it bit a bit, both alternatives being grim in their own way:

  • The big bang means a long period with the old and new application being maintained at the same time (each patch done on the production needs to be applied to the new system), without any new feature (which will not please the users). At the end, the deployment of the new system becomes something very complicated and risky, especially regarding the high expectation that the users will certainly have after having waited for so long.

  • The “replace the pieces” is a technical challenge in itself (make something new on the basis of something old is never simple) and the users will have to use parts of both applications during the whole rewrite period (losing whatever piece of consistency that may have been there). At the same time, each migrated component will require to be integrated in the blended system, and those successive operations will surely left traces even after the removal of the last part of the old system.

What is the ROI ?

As a developer, this is a question I got several times from my management, and that used to make me quite angry to justify, especially when the case was crystal clear (like, doing Unit Tests). Looking behind, not only do I understand the question, but I think it should probably have been asked more.

We are not doing software for the sheer sake of it (even if it may be enjoyable). We make software to make life (or business) easier. This doubly applies to rewriting, as your new application needs not only to work: it needs to work better enough to justify its added cost on a already running (and paid for) system!

The deciding rule should be the rewriting ROI, with indicators such as:

  • How many bugs are we getting on this each month? What time is spent fixing them?

  • How much is the application evolving? Do we get new features on a regular basis?

  • What is the mid-term plan for the application? Will it be replaced, stay there, or be used more and more?

Remember that for each point, having ROI in the new application is not enough: the difference between the current costs and the projected ones for the new application needs to be big enough (however good your new design may be, you’ll have bugs and code smells).

Finally, even if a ROI can be found, do not forget that one possible alternative to rewrite would be to buy an application to replace the old one. If the use cases are common enough, it probably does exist (every company and department thinks its needs are totally specific, and in most situations, they are wrong.).

Conclusion

My message and experience on this is not that we should never rewrite, but more that we need to make those kinds of choice with a product view, not a technical view. And this means in some situation to learn to live with the crapware that works good enough. It allows to concentrate on other, more important issues (that is: issues bringing more business value). Remember, development time (yours, your team’s, your company’s) is not an infinite resource: use it wisely.

Let them live, you have better things to do.

Solving the founder’s dilemma

May 162012
 

Remember this tweet from not so long ago:

“The entrepreneur’s dilemma: Maintaining friendships. Building a great company. Spending time w/family. Staying fit. Getting sleep. Pick 3.”.

I think I solved this dilemma almost without thinking about it. May be not completely, but mostly, with a single simple act.

Our current time schedule is (roughly): spend two days a week doing consultancy (we’re bootstrapping, so we need to get the cash flow from somewhere), the rest (which may be between three and five days) are spent on Sybil.

The time “on Sybil” itself means many different things, from (obviously) coding to customer development, via meetings with advisors, presentations or events preparation, networking, interaction with a designer, administration and I forget some.

All the points are important, all need to be given the proper attention and time, all of this in a mere 7 day-week.

As we do not (yet) have the money (nor, more importantly the necessity) to have dedicated offices, we tend to work from my home (I had more space to begin with). This has a very simple consequence:

As my girlfriend work out of town, we tend to wake up early, so by 7:15, I’ve taken my breakfast and are ready to “go to” work. One volley of stairs later (probably around 7:15:12’’), I’m at “my office”. When I begin to feel hungry around noon, I’ve already more than 4 hours of work behind me. The lunch is something that goes pretty fast when you just have to eat, and want to go back to work (which, as a Founder, you should). At the end of the “office day”, around 6:30 PM, the “work clock” is already around 10 to 11 work hours.

The best part is that, by stopping at that hour, I’ve still the time to go fetch some food and fix the dinner.

I’m not saying that I’m not spending evenings or weekends on Sybil, but as long as you are not an heavy sleeper (truth be told, there is an unfair advantage be able to rest in less than 6 hours), you can still get a good amount of work done, spend some time with your family and even keep some social life in a single day.

Elevator UX lesson : Genericity failure

May 032012
 

An elevator UX

This is a (very bad) picture I took with my phone, in the elevator of a modern looking-IT company hosting building.  Not being used to disruption in the rather bland world of elevator UX, I was struck by this “innovative” design.

The picture shows the various buttons allowing you to select the floor you want to go to. I can see the benefit of this in comparison of the more traditional “one-button-per-floor” design, at least for the company providing it: no more specific order (“Yes, our building has two underground levels, then the ground floor start at “2”), no more specific on-site work, the command panel is the same for everyone (after all, using this, you can select any possible floor on any building!), just have to put it in place, the rest is software.

And this “genericity” is precisely what is making it awful for its users for various reasons.

Genericity failure

Missing information

As an elevator user, what I want to know is on which floor is the company I’m visiting, and having this information right near the button makes it easy. No chance here, and although you could get it on a separate panel, it is not the place you’ll look at first.

Go where no man ever did

Nice, I can go to the 9th floor! Except the building was only 5 floor high, so half of this panel is actually not useful in this elevator. Actually, I can use this to go to the 666th floor !

Speaking of invalid commands

This “.” really puzzles me. It looks very useful to go to floor 1.1, or better yet, to floor 3.141592. A pity that architects do not yet use real numbers to define building floors.

Generic feedback

With so many possibilities to issue non application commands, the constructor had the wisdom to include feedback, in the form of the screen showing the current floor using a seven-segment display that cleverly shows an inverted E for any command deemed invalid (it should be sufficient for anyone to understand his error).

Conclusion

I’m probably stretching the experience somewhat too far, but this little funny experience made me think about genericity in UX by confronting me as a user to a situation where it was clearly misused.

We’ve all heard, talked and tried to apply as much genericity to our UI code as possible (creating reusable components to DRY, offering a library of standard widget in the context of enterprise applications, etc). One of my current coworkers even professes that every developer seems to follow the cycle : “dirty-do it myself code” to “code taking in account all possible evolutions (except the one that will happen)” to being somewhat more pragmatic in the approach.

Do not misunderstand me: the value of DRY and reusable components is real – it wins you time, time that you can use to deliver business value to your customer, but it cannot be done at the expense of the customer experience.

 Older Entries

Page optimized by WP Minify WordPress Plugin