As some of you already know, we’re working very hard to release a new version of LandlordMax Property Management Software in the near future (within weeks hopefully). As you’d expect, you’ll find lots of new and exciting features.

However not all features we wanted to include will make it into this version. For example, we tried to squeeze in a feature to give you the ability to “archive” older data. To give an example, let’s say you have a tenant “John Smith” that’s moved out some time ago, you might not want to see his name appear in the drop down list of tenants anymore. At the same time, you don’t want to delete him because a lot of older data is associated to him (such as all his rents, etc.). Therefore what we came up with is the ability to archive data such as tenants.

Seems simple doesn’t it? Should be easy. But it’s not as simple as it first appears. At least not if you want to keep your software easy to use!

Although I promise I’ll try to keep it as un-technical as I can, I’ll need to be a little technical to explain why it looks so easy at first glance. The obvious changes are that we need to add a property to the tenant to mark it as archived (in both the database and the code). Next we need to add the ability to mark a tenant as archived within the screen with a simple checkbox. Nothing too complex yet. But that’s where the simplicity ends.

You’re probably asking yourself how can it become complex from here. Really, all we have is a checkbox to mark an item as archived. If it’s archived, don’t include it in the list. Simple. Not so. Firstly, in your main list of tenants, do you display both archived and non-archived tenants? If you say just display non-archived tenants you’d be wrong. Before I give you the answer why this won’t work, ask yourself how do you edit an archived tenant if you only list non-archived tenants?

Aha! You can’t! Therefore you have to give your users the ability to see both. But then if you do, you defeat the purpose of having the ability to archive tenants. Well the solution we came up with is to include an additional filter at the top of the list. This way you can see all tenants, or only non-archived tenants. By default you’d of course show all tenants because not everyone will know there are filters when they start to use the software. And if you’re smart, you save the filter settings so that the user doesn’t have to reset it each time they go back to the list view.

That wasn’t so difficult. Of course if it ended there I wouldn’t be writting this would I. The next issue we have to deal with is what happens if someone tries to archive data that shouldn’t be archived. For example what happens if they try to archive a tenant that’s currently living in an apartment? Do you let them? Probably not. So now you have to create rules as to who can be archived and who can’t. Is it as simple as just allowing tenant’s that aren’t currently living in a unit? It would be nice if it was, but it’s not. It’s possible that a tenant has a lease to a unit that they’re not living in (a parking spot, a parent leasing for their child while away at college, etc.). So you can’t assume this. But for now, let’s assume you can ignore all this and just not let a user archive a tenant that’s currently in a unit (we’ll deal with the other issues later).

Have we solved all the issues? No, not yet. In our software we offer a dropdown (combobox) list of tenants on the other data entry screens. So for example, on the workorder screen you can select a tenant from a drop down list for that workorder. This makes life easier as all the tenant’s info is associated with the workorder (for reporting, printing, etc.). By doing this, we’ve just solved the issue of keeping the list of tenants to only relevant tenants (ie non-archived tenants). This is great.

But what about reports? How can we generate reports on archived tenants? Based on our current solution it’s not possible. For a user to generate a report on an archived tenant, they’d first have to un-archive that tenant, generate the report, and then re-archive them. Not very user friendly is it? And if we didn’t care about making life easier for our customers we could do just that. But of course we care, so that’s not an option. This means therefore that we have to alter all the reports that let you select a tenant to give you the option of listing all tenants or all non-archived tenants. Nothing too major, but we also have a lot of reports.

We’re still not done. What data do we use on our reports? On some reports we want to use archived tenants and on others we don’t want to use archived tenants. For example, on the reports that list all accounting entries or cashflow, we want to show all accounting entries regardless of whether or not the tenant is archived. However, when we display a list of tenants, we may or may not want to include archived tenants (another option the user needs to select). The same is true for reports on security deposits, leases, etc. So we need a way to toggle whether or not to include archived tenants.

What about reports grouped by tenant? Again same issue, we need a way to ask the user if they want to include archived tenants or not. Is just asking whether or not to include archived tenants enough? Unfortunately it’s not. Within some reports included in LandlordMax you have the ability to include a date range. For example, you can generate a rent roll report between any start and end date. You can generate a list of leases that will expire within a start and end date. Why am I mentioning this here? Isn’t it just as simple as including the option to include archived tenants or not? No. Well, yes, technically we could ignore this and just leave the responsibility to the user to deal with their own issues.

What do I mean? If someone selects to only display non-archived data isn’t that what they really want? Maybe not. Let’s say I want to generate a report that will list all “Accounting entries grouped by tenant” for last year. What do you think will happen? I might be missing half my data because half my tenants are archived. What about for the year 2001? Odds are pretty high that many tenants would be missing. Do we just ignore this use case and let the user deal with it. Never mind the support requests we may get from people complaining that many of their tenants are missing, especially since the data would appear on reports such as “All accounting entries”.

Assuming you’re still here and reading through this longer post, you can now appreciate how sometimes a simple feature can quickly escalate into a larger and more complex feature. In our case, we were hoping to squeeze in this feature for the next major release but I’ve had to make the decision to push it off. If we don’t, we have to address all of these issues. Well maybe we don’t, but if we want to maintain that we’re the easiest we definitely need to. At least I can’t knowingly release software with these glaring issues incomplete.

I can understand releasing software that’s fully working but missing some features (all software is like that, we can always add more features). For example offering the ability to send emails within the software but not offering a spellchecker is not that terrible (don’t worry we’re going to offer a spellchecker in the next major release). Your users can still send emails, they just can’t spell check. It’s not fun, but it works as expected. However releasing a feature that can allow your users to go into an unstable state (archive tenants that are currently renting your unit) or cause unexpected results is not good. Even if the software is behaving as it should, if the behavior isn’t what people expect there’s an issue.

And because of all this, the ability to archive tenants and other data has been pushed off. Especially when you consider the cost to benefit. The benefit of this feature is that the user doesn’t have to scroll through a longer (sometimes much longer) list of tenants that are no longer relevant. Yes it would be great to shorten this list, and I agree with the people who requested it, it is a much needed feature. But at this time the costs are too high and we’re too close to our release date. These are the hard decisions that no one wants to make but that must be made.

PS: If you ever wanted to know why software is sometimes delayed, this is a perfect example. This is a feature that seemed simple at first inspection but wasn’t. Actually even after some thought it still didn’t seem that complex. It wasn’t until we really started to implement it that we understood the issues and the full scope. And nor could we, how could you know ahead of time. In retrospect it’s easy, but think back to when you first started reading this post. Did you even have the faintest idea of what was coming up?

Discuss (1)