LandlordMax Property Management Software Status Update
Many of you on this site and on my company’s web site (LandlordMax Property Management Software) have been asking for more details about the next major release. When is it going to come out? What features will it have? And so on. Yes, the next major release is coming soon. Today’s entry is going to be all about it.
Working on this new version I suspect there will be some pleasant surprises for many of you. What we’ve done is take all the feedback and suggestions we’ve received through the Idea Initiative Program and used these to help drive what features made it into this upcoming version of LandlordMax. The feedback has been great! Thank you. And don’t think it’s ever too late to suggestion more improvements, we’re always excited to get feedback.
Before I go into details of what’s anticipated, here’s some quick previews and teasers: many new reports, report enhancements, table enhancements throughout, a new different database engine that is far superior, and so on. We’ve been working to bring this new release out as fast as possible, and it has posed some significant challenges. I’ll go into some of these today to give you a better idea of what’s going on and why were not likely to release it until at least the winter of this year (2005). Quickly, our most significant challenge and important change has indeed been the database engine. We believe we had to do this for several reasons which I’ll go into without hopefully getting too technical in this article.
Without further ado, let’s start looking at the status of the next LandlordMax Property Management Software release now!
LandlordMax Property Management Software Status Update
Firstly, and probably the most significant is the database engine change. We’re moving from an open source database called HSQLDB which is now being used to power the open source alternative of MS Word called Open Office to a database called Derby that was recently released to the open source community by IBM. This database was valued by IBM at $85 million! It has been sold and used by many highly valued commercial products and has been around for a long time. We’re very excited and proud to be able to provide Derby for you as your database engine!
From your perspective, there should be no visible changes at all with the new database engine change. If I hadn’t told you, you should technically never have known. If you did, then we didn’t do our job correctly of providing you with the easiest property management software in the market.
Why did we change database engine if you shouldn’t notice it? For several technical reasons which I will go into later. For now though, the quick benefits are that the database no longer has data limitations and is ACID compliant (don’t worry if you don’t know what that means, I’ll explain why it’s important to us later). The current database engine supposedly didn’t have data limitations, but we’ve recently found out that this isn’t necessarily true. Because of the way it’s been designed and built, the database is limited in data size to the size of memory it has allocated to it, more or less. Let’s take a quick somewhat technical look at that.
The current database offers something called Cached tables, which means that the tables can be written out of memory to the file system, allowing for large databases to be used. However, if you look carefully in the documentation it specifically states that the Result Set has to fit within the live memory. Without getting too technical, this basically means that if the data you are looking for is larger than your allocated memory space, then the database will return an error message saying it couldn’t complete the query. The good news is that virtually no one has encountered this yet, but I suspect it will happen in the future. To give you a scale of the limits, you would need to enter in about 50,000-100,000 entries on a normal installation to encounter this issue. Although this is more relevant to our larger customers, over several years this will eventually affect more and more people. Because of this alone, we’ve decided that it was better to act pre-emptively than wait until it became an issue, we don’t want anyone experiencing this. How horrible would it be to enter in many years of data for hundreds of properties only to have it eventually fail. No thank you!
The other major benefit is that it is a 100% ACID compliant database. ACID means: Atomicity, Consistency, Isolation, and Durability. The current database is not a fully compliant ACID database because they traded some of these requirements for speed. Because of this they were able to attain remarkable speeds in querying, however we’re now at the point where we believe it becomes more important to have a fully 100% ACID compliant database. The performance difference is almost negligible, 99.99% of you won’t notice, and if you do notice you have to be really quick!
The differences between the two databases in terms of ACID are:
Atomic: This means that you can do multiple database calls as if they were only one call, otherwise known as a transaction. This is important because if any single one of those calls fails, everything is rolled back to its original state. So for example, if you were a bank you could withdraw from one account and credit another as if it was one single database call instead of two (debit and credit). The benefit is that if you weren’t able to credit the second account (successfully complete all the calls), the whole thing would be cancelled and the money from the first account would be returned. The new database engine Derby is Atomic compliant. HSQLDB is not fully compliant, it’s possible to have “partially committed” transactions. Because the current version of LandlordMax doesn’t need to use transactions (each database call is currently atomic), this hasn’t been an issue. However, as we’re planning to offer a networked version next year, this will probably become more important soon enough.
Consistency: This means that the database will only write valid data to the database, otherwise it will rollback the transaction. As expected both databases support this.
Isolation: This means that multiple transactions occurring at the same time will not impact each other’s execution. So for example, if I start a transaction at the same time as you start another different transaction, both transactions should operate on the database in an isolated manner. That is, the database should either perform my entire transaction before executing yours or vice-versa. This prevents our transactions from potentially affecting each other in negative ways. The isolation property of a database however does not guarantee which transaction will be executed first, only that they will not interfere with each other. For the current version of LandlordMax this is not an issue since it is single user only. That is, there can only be one person using it at a time so it’s impossible to have two have conflicting calls.
Durability: This means that any transaction committed to the database will not be lost no matter what, it’s ensured through the use of database backups and transaction logs. The database will be able to restore itself in spite of any software or any hardware failures, no matter what! For us this is very important! With the first version of LandlordMax 1.00 we had some issues with HSQLDB sometimes not correctly shutting down because it’s not 100% compliant. Don’t be afraid, it’s very very rarely happens, and if it does happen it’s only the very last data you entered in the last milliseconds. Although this very rarely happens, it did happen. It was possible if you happened to be one of the really unfortunate people and shut down your computer at the exact wrong millisecond. Each new version of HSQLDB that we upgraded with each new version of LandlordMax helped reduce this, as well as some of the steps we took ourselves in the code. We were able to bring the number of failures down to 2-3 out of all our customers over the whole of last year, showing just how extremely rare it happened. That’s good, but not good enough for us! We’re expecting this to completely go away with Derby since it’s 100% ACID compliant.
The next biggest enhancement we anticipate seeing is the way the tables are displayed. One of the most requested feature enhancements we’ve received was to have some of the tables sorted slightly different, or to add new columns such as the priorities for the workorders. Well we decided to go one better than this and allow each and every table to be sorted by any column, including the reports just like in MS Excel. We also didn’t want to stop there, we’re currently investigating the possibility of letting you also choose which columns you want displayed rather than selecting them for you. We’ll of course offer a default, but you can manually change which columns will be displayed yourself.
While we were modifying the tables, we also wanted to go one step further, we want to add the concept of hierarchical tables, where you can collapse and expand sections of the tables. This way, if you have a report of accounting entries categorized by building, you can collapse all the buildings that don’t interest you so you only see their summary. We haven’t yet finished this feature, but we’re anticipating it will be available for the next version.
On top of that, we’re also hoping to offer searching functionality within each table. We haven’t decided if this is feasible because of screen real estate issues (there’s very little room left on the tabbed panels for lower resolution computer monitors which account for about 30% of our current customers). We’re working with our Graphic Designer Michael McGrath (which I highly recommend) to see if there is a way we can do in a very user friendly manner.
Unsurprisingly these table enhancements have been a technical challenge for us. Not just the implementation, but updating the sheer amount of tables we have in the software. Remember, we have hundreds of tables in the software. There’s over 100 reports alone!
Another significant change we anticipate is the ability to add your logo to the reports in an automatic way. Many property managers and companies have requested this and we’ve therefore added this ability. We’re also investigating the possibility of changing the titles of the reports, however we haven’t yet determine if this will make it into the upcoming version because of the complexity in presenting this in an easy to use way. I’ll explain in a little more details in the timeline section of this article why I say some features are anticipated and might or might not make it into the release, and exactly how we determine when and what will be released.
We’re also adding many more reports. Actually every release since the beginning has added more reports. This version will include more reports such as vacancy lists, rent rolls, etc.
Going on, we anticipate that all appropriate reports will now include graphs for quicker and easier understanding. For example, it’s much easier to quickly look at a graph to see how your cash flow has been doing than looking at a list of numbers in a table (or at least for some people). Although you need both, it’s amazing how much information simple graphs and pie charts can convey.
There’s also been other changes in the software. New fields have been added on some screens, the ability to print the amortization table, print multiple selected items from the list without needed to view them, performance enhancements, update notifications, etc.
When will the next major release of LandlordMax Property Management software be available?
Although I would like nothing more than to give an accurate and concrete date for when the next version will be released, I can’t. Unfortunately with software, it’s hard to determine when things will be done. I’d rather not be locked into a specific date forcing us to launch a version that has not been properly tested and is therefore not of the quality you expect from us. I’d rather postpone a release by a week or two, or whatever it takes, and get a better product out than one that is inferior, on time, and full of bugs. I think the most eloquent description of this philosophy was written by Joel Spolsky of JoelOnSoftware.com
That being said, we also don’t want to take our merry time getting a release out. Therefore we’ve adopted a semi-Agile development process. For those of you who aren’t familiar with the Agile software development process, I’ll try and describe it somewhat in a few sentences. Although it won’t give it justice, you’ll hopefully get the main concept.
Basically software development can be broken down into a list of requirements/features, that is a list of what needs to be done for the next version. Each requirement can be broken down further into a list of tasks, which is then distributed across a development team. The idea is that once all the tasks are completed for a version then you’re done your version.
Now there are many ways to deal with when the version will be released. One way is to determine which tasks need to be done, and adjust the date according to when the tasks are completed. Another way is to set a date and adjust the number of tasks to meet that date. Normally we prefer the second approach, but for this release we realized we would have to go with the first approach, adjust our date to complete certain key tasks. Then with the time remaining as we test and finalize the key changes, we will put in as many features as we can. Basically, this key task has become our critical path, the path that no matter what we need to take and we can’t finish before its completed. In our case, the critical path has become the database engine conversion. We cannot release until at least this task is fully completed and tested, no matter what. This is our most dependent task and it’s the one we need to watch the closest.
It wasn’t until very recently, just a month or so ago that we came up against the issue of database size. After investigating it, we needed to look at alternative database engines which took some time. In any case, no matter what database engine we decided to go with, we realized we would need to make changes to our code base. For example, without getting too technical, we took advantage of some of the database specific features of the current HSQLDB database engine, and worked around some of it’s difficulties. All these customizations need to be revisited. This also meant that our update and backup features would no longer work because they were specific to that database engine, more items to revise. We’re in the process of making these changes and more right now.
Actually, another key task is that we need to convert the database from one engine to another. That is, we cannot just simply copy and paste the content of one file to another, we need to provide a transition path that is invisible to our customers. Warning, if you’re not interested in the technicals, skip the text until you see the end of this warning. For example, we need to make a call to one database, say a select statement to get a list of all the accounting entries. We then need to call the other database to populate it with these same entries. That’s fine, but how does the software know this is the first time you’re running the new version and therefore needs to make the conversion (as well as which database engine to use). First, we check to see what files are in the database directory, this gives us a good indication of which database engine is in use. If it’s the HSQLDB database engine, then we run the conversion process, if not, we assume it’s already been converted. Now for the conversion process, we can’t just dump all the data into that database directory because once we’re done and we’ve confirmed that everything is ok, we then need to delete the old database files. There are multiple options on how to attack this task. Anyways, once the conversion is completed, we delete the old database files and move over the temporary new database files to it’s permanent position in the database directory.
You’ll notice that at this point, we haven’t talked at all the fact that we need to run LandlordMax with multiple database engines simultaneously and keep track of which is which, nor have we talked about the database specific calls. I won’t go into the database specific calls, but here’s a quick idea of at least one issue in the database conversion process. From which version of LandlordMax do we assume the conversion is coming from? Is it from version 1.00, 1.02, or 1.08, 1.08b, etc.? Each progressive update has different modifications to the database. In our programming code, we separated each database upgrade into another class, say DatabaseUpdate102, DatabaseUpdate108, etc. In the current version of LandlordMax, we have code that looks like:
Database100.createInitialDatabase();
if(database.isVersion100)
DatabaseUpdate102.process();
if(database(isVersion102)
DatabaseUpdate108.process();
This works very well because you can start from any version and you will see that the upgrade works. As a shortcut, as you can see in the code above, you can also create a new version by simply calling the same code. Now what happens if we change database engines? Does that mean that we leave the updates up to 1.08 to be created with the old version and always make the conversion after that, meaning that we will always have to ship with the old format? Probably not a good idea. Therefore we need to revised all this code to properly handle the database engine conversion.
Although these changes might look like trivial changes, they’re not. Again remember that we have some database specific calls in each of these that have to be modified. It’s definitely not impossible, it’s just that it takes time to be done right, and we want to do it right the first time!
End of technical warning
So now you have an idea of what’s involved in just converting the database. Once these changes have been implemented, we need to test them, and test them thoroughly. We need to test that the conversions work from new installations, from upgrades from each version (1.00, 1.02, and 1.08, 1.08b, etc.). We want to test every possible case to make sure that it works without any hitches and is unoticeable to our customers. To test this we therefore need to install and create entries for each version, the more complex and complete the entries the better the test results. For me to be personally satisfied that the new database will work 100% correctly, I suspect it will be sometime in the winter of this year (2005). Depending on how this goes, this will probably determine our release date. I’m currently anticipating it will be in December.
While I’m discussing some of the issues we’re facing, I figured I might as well also give you a better idea of what we’re facing when dealing with tables. As we’ve been implementing these we’ve found it’s a larger task than we originally anticipated. We quickly realized it would be advantegeous to us and you to purchase a component library from a vendor that does this, as well as a lot more. We calculated that everyone would be ahead. At this point in time I believe we’ve settled on which component library unless we encounter some unexpected issue.
Today, we have two main challenges remaining with the table requirements. The first one is dealing with the licensing of the component library. Although we believe we have chosen the component library and our test implementations look good, we still need to make sure the licensing fee to use the library is reasonable. We’re dealing with this right now. The second challenge is a technical challenge. In the first version of the software, we built a framework to assist us in developing tables that really accelerated the development of the software and allowed us to take some shortcuts because of this framework. Using a component library, we now have to do some conversion to our framework and test it for every case (and we have a lot of tables, over 100 just for the reports workarea) to verify that we’ve indeed properly converted each table.
Another challenge we’re still facing is the ability to print any column. This is not a technical issue, it’s a user interface issue. Currently each report (including table lists) are associated with a file in the reports folder which dictates how the table will be printed. In this file each column in each report is assigned a specific size (be it in millimeters or percentage of the page) to guarantee that all the printout looks good. The issue now is that these templates are no longer going to work because we don’t know ahead of time which columns will be printed, now how many. Then the question is; how much spacing should each column have? There are many options, of which we’re down to two right now. The first is that we manually ask you before printing. The second is that we use the percentages displayed in the table itself. We’re leaning towards the second option because option one makes the software more complicated to use and it doesn’t really give us much benefit (you probably want the columns on paper to look as close as possible to those on the screen). The second option of course is not without it’s own problems. Firsrlt, the print margins don’t match the printout. For example if you work on an 800×600 screen then you probably have more room on the paper than the screen. If you work on a 1600×1200 than you probably have more room on the screen than the paper. These are some of the issues we’re facing right now. These will be resolved before we release the new version, however at this time it’s still something we need to work through.
We’ve also been investigating the ability to add images to different workareas. Here the issue isn’t a technical one, it’s a user interface design one, that is how do we provide this feature in an easy and functional way. There are many options here, and unfortunately this is where the difficulties lie. For example, if we put a list of thumbnails in the tabbed panel for a building, then when you double click on it, does it fill in the tabbed panel? This probably won’t work so well for people who have smaller screens (800×600, which is about 30% of you). In these cases the image won’t be much larger than the thumbnail which is almost useless. Another option we came up with is to have a popup window for the images. In this model every time you double click on an image, you get a popup window with the image full sized. In terms of navigation, we could have this window close and popup again when you double click different images. This would work, but it’s kinda clumsy and it doesn’t fit with our philosophy of being the easiest. What about a forward and back button on the popup window? That might work. Another different option is to not use the tabbed panels and have a button in the top section of the screen bring up a thumbnail view of the images. Then from there you could navigate through the images. Right now we’re leaning towards either the last or before last option, and this is where having actually users test it will dictate to us which is better. Of course, there are other issues we faced with images but the major ones are not technical here yet.
We also looked into creating mailing lists. We looked for a component library that would assist us in this manner but unfortunately we couldn’t find one. If you know of a Java library that we could use for this, please email me. We started to implement this and that’s were we realized the sheer number of mailing label packages available in the stationary market. Therefore at this time it looks like we might offer a few standard pre-defined mailing label printouts. We’re not sure if we’ll offer the ability to generate custom labels for this version because of the complexity involved in designing such an interface and the time remaining until we release the upcoming version.
Other features that I can quickly talk about that we’ve already implemented include an auto-update reminder. In the past, when a new version of LandlordMax was ready, we would send out an email to everyone annoucing it so that they could benefit from their free upgrades. We found this method to be only semi-effective at best. Also, we don’t want our customers to be annoyed by emails from us, where we’re perceived as always sending out emails. Rather now what will happen is that if a new upgrade is released, the software will be smart enough to know and notify you when you next start it. If you don’t want to upgrade and not have it remind you, then that’s the end of the story. This way, we can guarantee that 100% of our customers know about the upgrade and we send don’t need to send any emails.
Another feature we added was the ability for the software, if you allow it to, to send us information in the rare cases that you do get an error. We’ve done this to allow us to continue to offer you the best, easiest, and most stable property management software on the market. This makes it much easier for you to pass on to us any errors you may encounter. The specific information that is going to be sent to us will be displayed on the screen, so that you can verify for yourself that no sensitive information is sent to us.
Conclusion
All in all, assuming we encounter no other major show stoppers like our database issue which substantially delayed our release date, as I mentionned before, we should be ready with the next major release sometime in December of this year (2005). As we get closer to the deadline, I’m sure you’ll start to notice more posts about LandlordMax Property Management Software on this blog. The good news is that if you buy it today (or after today), you get a year of free upgrades, which means you will definitely will get the next major release as part of your license. I’m going to go as far as to guarantee it right here that the next major release will 100% be within your license if you buy today or after today!
For those of you wondering when the next version after that will be released, rest assured we’ve already looking into this. Here’s a quick peak into what’s coming next year. Possibly a Mac OS version of LandlordMax. We’re also looking at offering a networked multi-user version of LandlordMax Property Management Software in 2006. Some other major features we’d like to offer are check printing, Quickbooks importing/exporting, and so on. The list is quite large and I’m sure we’ll get more precise with it as it gets closer to becoming a reality
