The #1 Programmer Excuse for Legitimately Slacking Off
Today I came across a comic that I just had to share. The fact that it’s too true too often is what makes it funny. The part that’s sad is that it doesn’t need to be.
In today’s day and age, where PC’s are now pretty much commodities, most software shops shouldn’t be able to use hardware costs as an excuse. Hardware is just so cheap in comparison to developer costs. Get a faster CPU, get more CPUs (maybe you do need a quad rather than just a duo). Get more RAM, it’s cheap. Get a high-end hard drive, that alone could double your performance. Get two drives and make a RAID-0 drive to increase the performance. SSD (Solid State Drives) are even affordable now and can significantly increase your performance. Spend the money it’s worth it.
If nothing else, calculate the lost time compiling, starting a server, whatever. Even if it’s just the difference of seconds, those can quickly add up. But when the difference can be calculated in minutes then you really have a case to upgrade your hardware. On top of the time wasted waiting while your box is trashing at full throttle, there’s also the time lost trying to get back into the groove of things, of remembering your train of thought. It quickly adds up and can make the difference between a successful and non-successful project.
And I haven’t even started talking about the advantages of larger monitors!
Permalink to this article Discussions (2)
LandlordMax Mac Version Update
A while back I talked about possibly offering a Mac version of LandlordMax. We bought all the necessary hardware, started work on it, we were very excited. If you follow this blog you’ll already know that after some time we ran into a few roadblocks. Nothing that insurmountable, we just got to a point where the cost to benefit ratio (the development costs versus the potential revenue) didn’t work anymore. It wasn’t that we were converting the system, it’s that there were certain UI (user interface) issues we didn’t know how to program on the Mac. Our knowledge is mainly Windows UI programming.
Therefore we ended up having to postpone the Mac version so nothing was moving. Then suddenly out of the blue Werner Randelshofer from the Quaqua Look and Feel posted a comment on my article LandlordMax Mac Version. I quickly replied and asked if he would be interested in helping us. This eventually led to an off-line discussion by email.
Before I go on, let me tell you how much of a stand-up person Werner is. We basically asked what it would take to have him help us, possibly even offering a small contract (you can even see this in comments for the article). For someone with his know-how of the Java Swing language on the Mac, this would have been easy for him to make a quick buck. It reminds me of the story I recently read on Friday Reflections, which to quickly paraphrase (and I’m doing the story proper justice here), it’s not the actual work effort that’s valuable it’s knowing where and what to do. Anyways, Werner instead suggested that he would be happy if “it contributes to the final solution for LandlordMax“. And that just an Amazon gift certificate or a bottle wine would be great. Thank you Werner, I really value you’re beneficence, it’s very appreciated. A lot of salespeople might groan at his beneficence, but you know what, it’s because of it that I’m sitting here today in front of my computer writing so positively about him and Quaqua.
Although I’m sure he never thought about it when he decided to help us (I have no doubt he was acting altruistically), he’ll probably get more benefit from his beneficence than had he charged us a very high quick one time bill. Firstly, we might not have taken him up on his offer (we already turned down one person who tried this tactic). And secondly as you can already see he’s getting his name out. He never asked to be written about, in fact he never even mentioned it. This is coming directly from me to show my appreciation. It’s my personal recommendation. And not only am I recommending him as a professional Mac Java Swing developer but I’m also recommending his product Quaqua. By the way Quaqua is free so there’s absolutely no reason you shouldn’t look at using it if you’re writing a Java Swing program for the Mac. On top of recommending him publicly, if we ever need more help with the future Mac version of LandlordMax I won’t hesitate to contact him. Who knows what this might lead to…
Therefore because of Werner’s contribution, we’re re-allocating back some of our efforts to working on the Mac version of LandlordMax. We definitely won’t be releasing a version 3.11 for the Mac, but hopefully the next major release of LandlordMax will be fully Mac supported. So let’s see where this journey leads us…
Permalink to this article Discussions (4)
Nine Woman Can't Have a Baby in One Month
Why is it that so many people continue to believe that software developers can do the impossible? In life there is always a critical path to everything, a path that you just can’t skip ahead. Yes sometimes work can be divided and thereby accelerated such as painting a room. You can get one person to paint four walls or you can get four people to pain one wall each speeding up the by four times. But if you want to apply two separate coats of paint you absolutely can’t get eight people to paint at the same time both coats. It just doesn’t work. The first coat of paint needs to dry before the second coat of paint can be applied. That’s a critical path you just can’t skip, no matter how much you wish it away.
However in software development a lot of people tend to forget this notion. There is a tendency to think that if we add extra developers to any effort we can shorten it by the amount of people we add. The thinking is if we add 20% more developers the time to implement the project should therefore decrease by 20%. The reality is that it doesn’t work this way. It’s not like painting a room. You can’t just grab a brush and start painting. It’s not that simple. Even if you’re the best developer in the world someone from the project still has to show you how to setup your environment. You have to learn how the software is implemented. You have to “get up to speed” which can take some time. This can take anywhere from a few weeks to several months depending on the project because of the inherent complexity of software development.
In some cases adding extra resources can even slow down your effort. For every person you add someone from your existing team needs to “bring them up to speed”, which means their not producing during this time. The closer you are to the deadline the more likely you are to slow the effort by adding new people to the team because of this training cost. They just won’t be productive quick enough to be worth it. They’ll probably only really start to get “up to speed” after the deadline.
My favorite analogy by far is the title of this entry, you can’t put nine woman together and expect them make a baby in one month. The critical path is nine months, no matter what you do. Some work just can’t be divided. Ever try to learn a language by dividing it up with several people while simultaneously skipping ahead some steps? And that’s what you have to anticipate with any software project. There will always be several critical paths.
Not only that, but sometimes one developer can implement a solution an order of magnitude faster and especially better than another developer . This is true in almost any profession. Just look at professional sports athletes, there is an amazing difference in quality. Can anyone beat Michael Jordan at basketball? Anyone want to play hockey against Wayne Gretzky? Every profession has it’s stars and its obvious that there is a difference among them, even among the elite of the elite.
The same is true with software and developers. I’ve heard sayings that an elite software developer can easily be worth ten junior developers. I completely agree. One Michael Jordan is worth several average players. Sometimes it’s worth waiting for a more qualified, or even just a specialized developer, to implement a solution. They might be able to do it in a way that will simplify the life of every other developer on the team and thereby reduce the total cost of the project today and tomorow rather than add to everyone’s effort. We’ve all seen patch jobs that take much longer to do anything with because of a bad implementation. That are buggy and needs to be continually fixed. That are just a complete mess. This is often the result of trying to push the critical path, of trying to apply two coats of paint at the same time.
Not only will you be ahead if you understand the critical path, it will also reduce your total software development costs. It will give you higher quality code which will lead to less bugs, less fixes, less workarounds, less hacks. It will lead to a better solution. Happier customers. Better maintainability. It will make improving and adding new features easier in the future. It will lead to higher employee morale. A better team. Lower turnover within the company. It’s just worth it. If you don’t believe me, just look at the statistics from this article on what happens if you push the critical path too much. Critical paths exist for a reason and it’s absolutely worth your time to acknowledge them rather than trying to wish them away.
Permalink to this article Discussions (11)
Windows Vista Read-Only
Since we released LandlordMax with full Windows Vista support, we started to notice a certain level of error reports coming with messages stating that the software couldn’t write data to database because the database folder was read-only. Obviously, if the database folder is set to read-only, it can’t write, but the big question is why are any database folders being set to read only? Was it specific to Vista?
At first it was only a few read-only errors so it was harder to nail down. But it didn’t take us long to isolate it to Windows Vista. Although we support Windows Vista, only a small percentage of our customers use it. I believe the current market share is somewhere in the the single digits percentage wise. But as time passes and we add more and more Vista customers, not to mention Vista growing their market share. It’s a growing issue for us and all other software vendors as you’ll soon see if you aren’t already experiencing this issue.
After a lot of investigation we discovered that the “read-only Vista issue” is very prevalent. It’s frustrating a lot of users! To give you an example of just how big an issue this is with Vista, I just did a Google Search and found these threads here, here, here, here, here, here, here, and here within seconds. A lot of people are complaining, it’s affecting a lot of software. But worse, it’s not just affecting the software applications but also the users data folders. For example a lot of people are also complaining that they can’t even edit their pictures.
Delving further into the issue, what’s happening is that Microsoft is trying to add extra security to prevent “Malware” from getting onto your computer. Whether or not this is the right approach is an entirely different discussion, but the downside is that it’s definitely causing a lot of frustration to their users! As I’ve already said a lot of people are complaining. Software vendors are getting hit with a lot of extra “support” costs to deal with this issue. After all, if the software doesn’t work, it’s probably the software vendor. Not in this case, but you can’t blame the customer. I initially had the exact same reaction. Windows Vista is still too new that most people haven’t yet figured out this is a Windows Vista issue.
On top of this, something we’re just starting to experience, sometimes if you change the file properties from read-only to read/write (ie uncheck the read-only file attribute), it comes back as read-only!!! What? I uncheck the checkbox, close the folder properties dialog window, and re-open it only to find the read-only checkbox selected. And yes I’m in Admistrator mode. I myself am confused and I’m nowhere near a novice user. I can only imagine the storm that’s going on as most people would have no idea what to do.
Up until recently all our customers could resolve this issue by just changing the folder permissions (at least as far as I know). Now this doesn’t always work. There’s no indication of what to do anywhere within Windows Vista. It changes your settings without you wanting to. I’m personally at a loss and will be contacting Microsoft on Monday to see what’s going on.
I have no doubt that they will have to revisit their decision on this aspect as they gain market share and it becomes more obvious what’s happening within the community at large. I can only imagine the scale of the storm that’s already brewing…
Permalink to this article Discussions (138)
WhichJar.com
In the last two days I’ve created and launched a brand new website aimed at Java developers called WhichJar.com. The site is now live even though the database is pretty empty (I’ve only added a couple dozen Jars so far). I’m working with someone to fill it up with lots of data very soon.
What does WhichJar.com do? For those of you who program in Java, often you run into what I call “Runtime Jar Hell”. Basically what this means is that you set up a project and everything compiles, but suddenly when you try to run it (your J2EE app, Swing app, etc.), you’ll get class not found exceptions. What’s happening is that one of the Jars you added to your project also requires other Jars for it to run (they are only required for runtime, not compile time). It’s very easy to miss these, and all you get back from the runtime engine is the name of the class it can’t find. If you then try to Google it, often all you’ll get is the API, from which you then need to do some sleuthing to actually find the right jar. This is extremely annoying and boring!
One of the newer tools out there that’s supposed to help minimize this is Maven, but that’s also got some issues. And not everyone uses it. So for those of you who get caught in Runtime Jar Hell, I’ve created WhichJar.com. All you do is enter in the fully qualified class name and it will tell you which Jar it belongs to, where to find it (the website and download URL), the version, release date, etc. Instead of spending a lot of time trying to find it online from the API (which is not always obvious), it’s all right there for you in an instant! Click here to see an example result page.
Again, as I’ve said before, the database is pretty empty right now but that’s going to change with time. We’re adding about 100 new Jars a week and I’ve hired an outside source to generate me a much fuller and larger list for the very near future. So hopefully within a month or so it will be full of data and extremely useful.
So please go ahead and try it. It’s very handy and it can save you a lot of time!
Permalink to this article Discussions (3)
How to Save on Bandwidth Costs
Reading many ISV (Internet Software Vendor), uISV (Micro ISV) blogs, etc. you often hear how bandwidth costs can sometimes quickly escalate with success. Jeff Atwood of CodingHorror.com posted an article (with a nice follow-up) on this very subject describing many things you can do to minimze your bandwidth costs. These are:
- Switch to an external image provider.
- Turn on HTTP compression.
- Outsource Your RSS feeds.
- Optimize the size of your JavaScript and CSS
All great options, no doubt about it. But another option that is very often overlooked by software companies is the size of their software installers. It’s very easy to forget, never mind completely miss, the size of the installer. For us here at LandlordMax it was always an issue because we also install a local JVM which is considerably large. With each new version the size of the installer steadily increased until it was about 36Mb. This might not seem so big compared to some of the other larger software applications in the market, but when you’re looking at thousands of downloads a month this quickly adds up to a lot of bandwidth.
Late last year we changed the software we used to create our installer to Install4j (you can read my review on this great installer here) and it was able to drastically reduce our installer size by about 50%! Yes, that’s a full 50%! What does that mean? Well if you consider that the majority of our bandwidth is used for downloading LandlordMax, then we were able to reduce our bandwidth by about 50%.
None of the suggestions above could have reduced our bandwidth nearly as much as this one change to the installer. On this blog (FollowSteph.com), the above four suggestions do indeed have a very significant impact, but on LandlordMax because of the nature of the website, the change in the installer completely overwhelmed any of the impact these changes would have had. This is not to say that I don’t strongly believe you should do them, but that in this particular instance another tactic to reduce bandwidth was much more crucial.
So the lesson of the day, other than to do the above great suggestions by Jeff (especially for blog type websites), is to look at your software installer and see if you can’t reduce its size (assuming you’re a software company). The impact may be more significant than you might realize.
Permalink to this article Discussions (0)
LandlordMax Mac Version
As many of you already know, we’ve been hard at work on a Mac OS X version of LandlordMax. So far it’s been going pretty well. Most of our issues in supporting the Mac have been visual, with very few real technical issues. That being said, we are currently experiencing two visual related issue that we’re finding harder to resolve. I know we’ll eventually figure it out, but I’d like to get the Mac version out sooner than later. Therefore, I’m putting out a help request to all developers who read FollowSteph for this one issue. If you know the answer, or if you have good pointers, I’d love to hear them. And if someone points us to a direct solution that we use (or the first person if there’s more than one), I’ll send you a $100 Amazon gift certificate to show my appreciation!
Before dwelving into the technical aspects, here’s some quick background. LandlordMax is written in Java, and therefore the port to the Mac OS has been relatively straightforward as I just mentioned. Although many of you might not know this, from the very beginning we programmed almost everything in LandlordMax to be operating system independent. Although it wasn’t always possible 100% of the time, it was for the vast majority. The biggest issue, as I alluded to above, is the visual look and feel and how that affects the screens.
The two biggest issues we’re currently encountering which we’re struggling with is related to the combo box (pull downs) within LandlordMax. In Windows, the combo boxes are the same size as the text fields whereas in the Mac OS they’re much larger (especially in regards to height, and only somewhat in length). Because of this, and because we have to suppport the 800×600 resolution (a full 15-20% of our customers still use this resolution), we’re very limited in screen space. What’s happening is that these combo boxes on the Mac OS are taking up much more space than they should, and hence pushing things down on the screen (and sideways as well). On some screens this isn’t a big issue, but others were space is very limited (for example the Scheduled Tabbed Panel), this means that some of the fields no longer show up on the screen, they’re pushed down off the screen.
Below is a screenshot below of LandlordMax on the Mac OS. What we’d like to do is bring the combo boxes down to the same size as the fields.
The second issue has to do with auto-fill combo boxes, such as the “Type of Payment” field in the screenshot. For some reason, the auto-fill combo boxes are not being rendered correctly. If you look at the screenshot closely (you can click on it to see the full sized screenshot), the field has half of the combo box missing. I suspect this also has to do with the same issue.
So far we’ve looked at a number of solutions which haven’t quite worked for us. The first, and what looked like the most promising, was the QuaQua Look and Feel. They’ve noticed this issue as well us and have rectified it in their own custom Look and Feel. When we implemented it, it did indeed resolve the combo box issue, but unfortunately it also caused many other issues. With this Java Look and Feel, they seem to overwrite many of the manual settings we programatically apply in the software. So for example, if we set a background color of light blue on a panel (or component), it seems to ignore this and apply it’s own Look and Feel. Therefore this solution isn’t quite working for us right now.
We’ve also looked at modifying the Java Look and Feel by just changing some properties, but as we’re not familiar with this aspect of the language (actually very few people are which is why I’m posting it here today), it’s just not working out for us as we intended. We’ve had some moderate success with this solution but not enough yet.
There are some other solutions we’ve looked at, but as far as I can tell, the best solution is to modify the existing Look and Feel. Either by modifying the Mac OS Look and Feel or by extracting what we need from the open source Quaqua project…
If any of you know how to do this for the combo box that would resolve both of our issues, I would be extremely grateful. Not only that, as a show of my appreciation, I will award a $100 Amazon gift certificate to the first person who can give me a direct solution that we end up using!
Permalink to this article Discussions (11)
A Large Monitor is Actually Cheaper Than a Small Monitor
No matter where I go, I always see it. Every company that I know of, with the exception of a few companies, are more focused on saving pennies by getting their employees the smallest monitors possible that they can get away with. Why? Because they don’t believe that a larger monitor is worth the investment. But then again I also see many of these same companies skimping out on hardware for the same reasons. The bad news for them, good for me, is that studies have shown that larger monitors do significantly increase productivity as shown here, here, and here.
The reality is that the extra costs to invest in a better monitor, or better hardware, will generally be returned to you in multiples. I personally work on the Dell 24 inch widescreen LCD monitor right now, and I can’t rave enough about it. The only complaint I have is that it’s not the new 30 inch LCD widescreen monitors that Dell now has available!
But really, the reality is that I’m so much more efficient on the larger monitor that the time saved makes incredible sense for me. Comparing the price of a 17 inch, or even 19 inch monitor, yes I’m paying substantially more. But you know what, I’m also a many more times more effective!
But the real question is just how much more effective? Well let’s break down the numbers, there’s no better way to determine the value than looking at the bottom line. At this time of writing, a 24 inch Dell wide screen costs $800. An equivalent quality 17 inch monitor can be had for as little as $150-200, so let’s use the smaller number of $150. Therefore the price difference is $650. All I need to do to justify the extra cost is find $650 of value over the lifetime of the monitor, which we’ll assume is at least 3 years (probably more). Breaking it down even more, all I need to do is increase my value by $650 / 3 years, or approximately $213/year. That shouldn’t be too difficult! In reality, I’ll get a LOT more value than $213/year, not counting the joy of using it!
Ok, so let’s look at the value. Below this paragraph you can find three screenshots of the Jakarta Struts project in Eclipse. The first at 1920×1200 resolution from my 24 inch widescreen monitor. The next one with the same screen settings showing the coding section truncated, and the last one how it would normally be displayed at 1024×768. As you can quickly see there’s a huge difference in screen real estate space! If I was just using Outlook, Word, or even an internet browser, it wouldn’t make that big of a difference, but for programming purposes it’s a very large difference.
For those of you would aren’t as familiar, let me walk you through the screenshots to give you a better idea of the real estate value. On the left we have our project structure (almost like Windows Explorer). When programming, you separate the code out into logical files to make your life a LOT easier. Therefore you’re always referencing this panel all the time. And sometimes it can get quite deep, with many nodes on the trees as you can see in the screenshots), so it can take some space (much like if you have many directories within directories on your computer).
After that you have your console on the bottom panel. This panel is also use a LOT! This is where information from your program is outputted. This can range from debugging (sending out diagnostic information to the panel while the program is running to give an idea of what’s going on), to bigger things like displaying program error message, etc. The more space you have here, the more diagnostic information you can display, otherwise you just end up scrolling the panel a lot.
Next we have the optional Outline display on the right. On smaller screens this is often omitted because there just isn’t enough space, even though it’s very handy and helpful. What it does is give you a succinct list of all the methods, properties, etc. of the class (or classes) within the file you’re currently editing. This might not seem like much, but imagine if you have several hundred lines of code (best of luck if it’s thousands) and you’re looking for a particular method? Instead of always having to scroll through the code or doing a search for the text, you can quickly see the list and just double-click on it to move your cursor there in a second.
Lastly, and by far most importantly, is the main panel in the center. This is your programming code! This is where you will spend most of your time and where you want to see as much as you can. Often an algorithm will be spread across a decent amount of lines, possibly over several pages (multiple methods, etc.). The bigger this space is the better! I can’t stress this enough. Think of it as a working piece of paper when drawing plans for a house. The more you can see at once, the better off you are!
As you can quickly see from the screenshots above, with a smaller screen you have to start sacrificing space right away to be able to see everything at once. And don’t think that you mainly use one panel at a time, you generally move around between the different panels very frequently as I’ve just described. It’s much like driving, you look out your windshield, then your rear view mirror, your speedometer, and so on. Always moving your eyes around as you need to get more information. The same is true when developing.
That being said, if you look at the amount of real estate space on the smaller monitor, you have to make a lot of sacrifices. Going back to the car analogy, you don’t have the dashboard space to see everything at once, so you have to cut into some of the information. So for example, you can only see half of your speedometer (showing only the most common speeds in that window). You can only 1/4 of your rear view mirror, so pick the most advantageous spot. You can only see out 1/4 of your windshield, so definitely pick the area directly in front of the driver’s side, near the center preferably.
So right away, you’re limited in information, you can’t drive or program at nearly the same speed. The good thing though is that you can resize any of these windows as need be, but each time it costs you time and you have to sacrifice another panel. So for example, if you want to see out of your complete windshield, you can’t see any of the other windows (rear mirrors, speedometer, etc.). You can also just partially increase the size of any one window but you must also relatively decrease the size of the other(s) to compensate. As well, each time you adjust the size of a window, it costs you time. For programming, this means you have to move your hand to the mouse, adjust the size, etc. It might only be 2-3 seconds, but do this hundreds to thousands of times a day and it quickly ads up; 400 seconds to 4000 seconds – 6 minutes to a full hour!
Each time you make an adjustment, you lose other information, so if you need to move back and forth a lot, you’ll probably lose a little bit of the context. If you spend 1/2 your time adjusting the sizes of the windows, it’s easy to quickly forget simple details such as the speed you’re driving at, which means another adjustment, lookup, etc. This ads up.
Assuming your programming pretty consistently (ignoring things like attending meetings, being tired on Monday, etc.), I’ll use the one hour metric for our calculations, and then I’ll follow up with the 6 minutes to show that even that’s worth the return on investment!
Ok, so getting back to our calculations, assuming about 200 workdays, and assuming 1 hour is lost each day, that represents 200 lost hours of labor. But before I go on, I’ll just take a minute to talk about the cost figure I’m going to use for a developer hour. In a previous article I used $1000/day per developer, which caused some people to comment that this was too high. The reality is that this isn’t too high from the businesses perspective, this is the cost of a developer. The developer won’t receive $1000 in salary, they’ll just receive a portion of that. What you have to remember is that the business also has to pay for the employees benefits, real estate (for example IBM saved $700 million in real estate costs by having workers work from home), hardware, software, etc. All these things quickly add up!
Anyways, assuming a $1000/day cost for a developer (or $125/hour) , giving that they lose 200 hours a year because of the size of their monitors, that’s a $25,000 difference in cost. So you just lost $25,000 in productivity to save $800! If you like those kind of deals give me a holler, I’m sure I can provide you with other similar great deal!
Now what if I grossely overestimated my numbers, which I didn’t but what if, then that’s 200 days * (6 minutes/day at $125/day) = $2,500. So even at 6 minutes a day, we spend $2,500 to save $800! Wow!
To add on top of this, in the above calculations we assumed our monitor would last just one year (200 working days). So multiply the above numbers by 2-3 times since most monitors will easily last longer than that! You can quickly see how valuable a larger monitor becomes!
To add to this, getting a larger monitor will also make programming much more pleasant to your developers, which means they’ll be more efficient. No you can’t really measure the benefits here directly, but rest assured that they do exist. If you go with high quality monitor, your employees will be less tired (it’s less hard on the eyes), and so on. With LCD’s I also found that it significantly reduced the number of headaches I personally got, so that’s another measurable benefit in terms of productivity.
All in all, as you can quickly see, a large monitor is actually much cheaper than a small monitor when you consider the total value of your purchase. If you only use it to surf the internet, send emails, etc. then you’re absolutely right, there’s no real benefit in terms of dollars. But if you program on it, the return on investment is incredible!
Permalink to this article Discussions (27)
Why It's Important to Test in Production
Every real software developer I know knows the importance of testing their software in a production environment because there’s always that slight chance that something may be different from your development environment. This is why in enterprise software you have a development environment, a staging environment, and a production environment. The development environment is as you might expect, is where things are tried out. However staging is where things get different, this is where your environment should replicate as closely as possible your production environment. Although it’s not always entirely possible to completely reproduce it, the closer the better. And production is your live environment.
Normally for LandlordMax, when we’re developing we run it directly from our IDE (Integrated Development Environment), which is our development environment. If everything works here, it should work in the production environment. You always want to test it in staging though, just in case, which we do. Also, to remove the chances of errors, what you also want to do is automate the process of taking your development application and “productizing it”. That is to say, you want to create something called a build script which will automatically create everything for you, removing any chances of human errors in creating the final product.
Once that’s done, at least for us here at LandlordMax, you have an installer created. You then try the installer. You then run the software to make sure everything is still working the same (hopefully someone else will do this to avoid any biases while testing). It’s a pretty simple process.
However with version 3.11 of LandlordMax we re-learned the valuable lesson of just important it is to test and re-test the software after it’s been productized. Yes we normally run it through it’s gamut of tests, but for some reason we missed one simple test case with version 3.11 that where we just a few minutes ago released version 3.11a tonight to correct. The bug, which worked in our development environment, didn’t work in staging, or production. Unfortunately it wasn’t caught until just recently by two of our customers, which I personally thank you for letting us know so quickly. The good news is that because they contacted us right away, within 1 day we have a new version with this fix available!
So what happened between the two environments, shouldn’t they be the same? Yes they should be the same, there should absolutely be no difference. However this was not the case with version 3.11. But before I get into the details, let me step back a minute and explain what happens in our automated script (which by the way was not at fault for those of you thinking ahead).
Our build script consists of several steps. First it gets the latest code from our version control, compiles it, and creates the appropriate objects. Once this is done, it grabs all the appropriate resources (for example images, etc.) and puts them into their appropriate objects. After that, it takes these objects and “Obfuscates” them (if you’re interested there is a famous contest held each year to see who can create the most obfuscated code called IOCCC). This is important for us as a company because it takes the compiled objects (intellectual property) and makes it extremely hard to reverse engineer. Nothing is impossible, but I can tell you from looking at the code after the obfuscater has run through it that I can barely understand it myself! Anyways, once this is done, it takes all the objects, and runs another script which then creates the installer (LLMaxSetup.exe) which you download and install. That’s our build script. Not too complicated, but not too easy either (I’m glossing over some of the details).
What happened with version 3.11 is that we updated the software that obfuscates LandlordMax. We’ve done this many times over the last 4 years, but this time for some reason it changed the way it reads the configuration file. Not significantly, but enough that it caused this issue. Without being too technical, in our code we overwrite a few libraries we use (for example we changed how the report printout calculates the report totals by adding a clause for “NSF” checks, and so on). Now when LandlordMax tries to call this library, our code is intercepted beforehand and is used rather than just going directly to the library’s code. Nothing major, this is called “overwriting” in programming. However, one key feature in overwriting code is that you need to use the exact same names!
Well to our dismay, the configuration in our obfuscater no longer accepted the wild card we used in the past. It overwrote the names of these classes, and therefore because the names weren’t the same, our code didn’t intercept the library’s code. And because of this, the software didn’t know how to handle “NSF” or other little tweaks we added! Hence all the totals were $0.00 on the printout.
So between our development environment and our staging environment something had changed. Something that wasn’t suppose to change, had never changed in the past, but suddenly now did. This is why it’s important to thoroughly test your final production product. We did, but we somehow still missed this issue and for this I apologize to all our customers. We have therefore just released a new version (version 3.11a) that you can download and install to resolve this issue right now.
PS: As an aside, I’d just like to say this was a fairly difficult bug to track down. This is a bug that worked in every development environment but not in our staging or production environment, regardless of the settings and configurations! It also illustrates even more the importance of properly testing in every environment!
Permalink to this article Discussions (3)
Just How Important is Your Software Installer?
Most people probably think it’s not that important, as long as it just works and installs your software for you. However the reality is that this is far from true. Your installer is the first impression people have of your software, and you only get one chance! If it doesn’t work, if it’s hard to do, it will cause a negative perception of your software before they even have a chance to try it! I don’t know how many of you are familiar with Zune, but this software is getting a horrible reputation online because of how difficult it is to install. Just look at the size of this review, it doesn’t really talk about the software, it’s all about how horrible the installation process is! So why start with a negative against yourself when there’s no need.
Not only is it your first impression, but just as importantly it’s not part of your core product. So in other words, not only is it important to do right, you also don’t want to spend too much time on it (it’s used only once) and it’s not your core competency. Talk about contradicting priorities!
Therefore, that being said, I strongly suggest you look at a software solution that will build your installer for you. Some of them are great, others not so great. Not only that, but they also range in price from free to very expensive, as well as in complexity, and what you can do with them. Before I start to go into details, just to give you a disclaimer, we at LandlordMax now use Install4J which I strongly personally recommend.
Getting back to the discussion, I’ve personally used 4 different installer packages in my career, including 3 with LandlordMax alone (there is some overlap). The first installer I ever played with was a custom built installer for the company I was working for at the time. Yes this solution worked, and it had by far the most customization, but it was also the most expensive to maintain and support. It’s really a second application for the company. They eventually moved to InstallShield, which at the time was one of the better solutions (this was many years ago). It worked, it definitely simplified the installer process. Now although I said it simplified it, it wasn’t the end all be all solution by far. If I remember right (this is a long time ago), every wizard screen had some code behind it in InstallShield’s own proprietary language. And at that time if you clicked on the back button, it didn’t remember the state you were in, which resulted in some very crazy scripting code.
Moving on to today and LandlordMax and skipping several other installation experiences, we initially started with InstallAnywhere. One of our requirements was that the installer we used also install a JVM with the local application. I don’t remember why I picked InstallAnywhere, this is about 4 years ago, but that’s the solution I chose. After a couple of years, we also started to use NSIS (Nullsoft Scriptable Install System) for our patches, which created much smaller installers (the patch installers just overwrote some files in the application directory versus a full install). I used NullSoft for the patches because it was a much quicker and simpler installation than InstallAnywhere.
At several points, we even looked at using NSIS to fully install LandlordMax, but let me tell you this is a complex endeavour! Although NSIS is a great little installer, it’s all script based. That means you need to learn another programing language. Not only that, but you need to become proficient in it do anything beyond the basics. Yes, we could learn it, copy snippets, etc., but from that point on we’d have to keep maintaining it. Someone would always have to be familiar with the language. This might seem like a small factor, but let’s say the “Installer person” quits? We have to find someone with that skill or train another person. Very expensive! Especially having gone through something similar with my first installer experience, I’m not willing to go that route again.
Since I wrote about JProfiler here on my blog, the people who make this amazing software contacted me to tell me about their installer solution called Install4J. After a few emails with them, I decided to give it a test run, and boy am I glad I did!!! They’ve created an amazing installer that’s in the same league as their code profiler! Within 1 hour I had created a brand new and fully functional installer for LandlordMax, including time to read a couple of advance features in the user manual! That’s amazing! Not only that, but if you consider the human resource costs of learning an installer like NSIS and the cost of Install4J, Install4J wins hands down!
I did mention that we were using InstallAnywhere as well. After trying Install4J, we decided to convert entirely over to Install4J and stop using InstallAnywhere. It was a good product for us at the time, but it’s now time to move on to a great product like Install4J. This is why in the upcoming version of LandlordMax later this month you’ll see a new look and feel to our installer. We’re now using Install4J for all our installers.
Why did we convert over? For several reasons. First, it was just too easy to learn and use. To do the same things I did in InstallAnywhere in Install4J takes me a fraction of the time. And I’m not the only one who thinks this way, the following thread on JoelOnSoftware has other people expressing their sentiments on the unnecessary complexity of InstallShield (same family of products as InstallAnywhere).
It’s not just the complexity of creating an installer, it’s also the ability to perform tasks. Everything seemed intuitive within Install4J. To give you another example, let’s say you want to install an application local JVM with your installer, you don’t need to go download it from their website (never mind finding it on the website which always take me a while) and put it in the right file location for the software to pick it up, they have it built right into their software. You just select the JVM version, and if it’s not there, you just press the “Download JVM” button right below which lets you pick it from a list. It then automatically downloads it, installs it, and you’re ready to go. No need to do anything more.
Another feature I really liked about Install4J is it’s ability to compress the installer itself. With InstallAnywhere last installer had grown to over 35MB in size. With Install4J, our new installer is going to be about 15MB, and this is with a bigger install on top of that. That’s more than a 50% drop in download size! This might not seem too significant, but remember that if you have thousands of people downloading your software, it sure can make a large reduction in your bandwidth usage.
Something else I really appreciated, which I have to admit I’m not as familiar with in InstallAnywhere, is the ability for it to use files relative to the project file. Why is this important? Because I can use the Install4J installer script directly within an Ant task! I build my main Jars, pick up my other Jars and resources, and away I go, all from within the same Ant script. I can now check the installer script right into CVS, and any other developer who has a license to Install4J can create their own test installers! WOW! Yes you generally don’t need to do this, but when it comes to testing an install environment versus your local environment, there’s no faster way to get the latest install than just generating it yourself within your IDE at will!
Another thing to realize with Install4J is that it’s not limited to just Java applications. Actually I’d say it’s amazing for Java applications, but you can use it to install any type of software. They have hooks for pretty much all types of installs. It’s just that for us, we also need the ability to install an application local JVM, which greatly limits us in terms of which installer solutions we can use. If it wasn’t for this limitation, I would still use Install4J, it does everything you need your installer to do and more. For example it has the different install modes (silent, graphical, etc.), multi-platform support, multi-language support, etc.
As an additional little tidbit of information which really excites us, from what I understand the fine people at Install4J are looking at potentially extending their API to allow hooks into your own software application for auto-updates in an upcoming version! What this means is that you’ll be able to use their knowledge and technology to allow your customers to click on an “Update” button directly within your software which will update it, without the need to download and install a patch. This is great! Yes, we could build it ourselves, and we actually did look into it. From our calculations, it would take at least 2-4 weeks, so let’s say 20 days * $1000/day (this includes salary, benefits, etc. i.e. all the costs for one developer), then our costs is about $20,000. If we can outsource this technology, assuming the highest price point, we come out ahead by more than an order of magnitude! And not only that, this is their field of expertise, their core competency, and they will maintain and update the feature for us. We could instead spend those resources building other highly valued features that are unique to LandlordMax.
Therefore, as you’ve seen, your choice of how you build your installer is important. First, it’s your first impression, so make it a good one! You only get one chance! As well, since your goal is to minimize your costs in this area, you should look at purchasing a solution rather than building a custom one. If I had to calculate the costs of a custom solution, well any of the installers available today on the market would probably be cheaper. Even NSIS, which has many copy/paste scripts available is still fairly expensive in developer time. After having used several alternatives, I’m strongly recommend you check out Install4J. This is the one we’re going to be using from now on, it’s the best one I’ve ever worked with!
Permalink to this article Discussions (5)
| « PREVIOUS PAGE | NEXT PAGE » |
