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)

---