“How many times have you had to debug your web pages on virtual or multiple machines running different versions of Internet Explorer? Or had to wait for a slow web service to return renderings of your pages?

You don’t have to do that anymore. Now you can debug your pages on multiple versions of IE on the same machine that you use for Web development.”

From the MSDN Blog about Microsoft Expression Web SuperPreview. Found while searching for the next best thing after Multiple IE, an earlier solution to let web designers and developers test their pages in multiple versions of the Internet Explorer web browsers. Multiple IE is no longer supported, and IE8 is out, so Microsoft’s Super Preview software looks like a decent alternative. (The only problem? Take a wild guess. The software is bloated, 250MB. Probably worth it since it is a Microsoft solution to a Microsoft problem. But you’ll need extra time to download their software.)

Other options appear to be IE Tester and Xenocode Browser Sandbox.

The most lightweight option probably is WestCiv’s X-Ray bookmark utility. It is hands down the slickest utility for web designers. Select the X-Ray bookmark then click any part of any web page and see all sorts of useful detail. I can’t get X-Ray to work with IE6, to show me all those nasty bug effects, but X-Ray does work on IE7, Google Chrome, Safari, and Firefox. So it’s a very lightweight easy solution to figuring out how your pages are being rendered across multiple browsers. And how somebody coded a neat web page design.

UPDATE (8/22/2009): If you install the Xenocode Browser Sandbox, and want to remove it, be aware that you may need to remove multiple instances of their software through the Windows Add/Remove Software screen. Also, in your Windows Task Manager (Ctl + Alt + Del), in the Processes tab, Xenocode software shows up as Spoon-Sandbox.exe. It’s a bit obscure. I had installed Xenocode for testing only to see, months later, that every day it loads spoon-sandbox.exe even though I don’t use the software. If you’re compulsive, like me, and want to know what is on your computer, now you know.

UPDATE (11/13/2009): Today there is no need to download software like Super Preview to view your application in different web browsers. Adobe’s BrowserLab currently is free and available anywhere with a modern browser. It’s easy to use and displays the full range of bad browsers, specifically, IE6 and IE7 on both Windows and Mac. But it also shows Chrome, Firefox, and Safari. Browsercam also has updated their service to display your pages at a variety of screen resolutions. I have used Super Preview and while it is useful, it is harder to navigate than BrowserLab and the latter does not require a massive download and installation of software.

UPDATE (02/15/2010): Added a link to the release Microsoft Expression Web product. Unfortunately, the SuperPreview software is no longer free. You have to buy the whole software package. BrowserLab probably is the better option, as a result, unless you need to identify exactly what is wrong with how Internet Explorer displays your web page. In that event, SuperPreview provides excellent detail about the code and makes it relatively easy to find and fix problems.

“Having a good program manager is one of the secret formulas to making really great software. And you probably don’t have one on your team, because most teams don’t.

Charles Simonyi, the brilliant programmer who co-invented WYSIWYG word processing, dated Martha Stewart, made a billion dollars off of Microsoft stock and went into space, first tried to solve the Mythical Man Month problem of organizing really big software teams by creating one super duper überprogrammer writing the top-level functions, while handing off the implementation of the lower-level functions to a team of grunt junior-programmers as needed. They called this position program manager. Simonyi is brilliant, but this idea, not so much. Nobody wanted to be a grunt junior programmer, I guess.”

From Joel on Software. This is an excellent, perhaps exhaustive, description of how best to manage software development projects. It’s a wonderful read, too. This article is excellent background for non-programmers as well as anyone involved in software programming.

In theory, software development should be amenable to the same processes used for any large scale creative project, for example, paintings where the assistant(s) set up the general work and the artist fills everything in, architectural photography (same dynamic: assistant(s) set up, the photographer comes in to add value), and so on. But software is notorious for failing when traditional organizational methods are used, as Spolsky notes in the quote above.

This article also has great insights, for example, making sure the program manager and programmers are peers and equals. This guarantees debate. Otherwise, if programmers report to the program manager or, worse, the development manager also is the program manager, then there is no debate among equals. Bottomline, the software program manager must be an advocate for the user and must earn the respect of the programmers and win them over to their user-centric solutions.

“Busy practitioners are sometimes reluctant to spend time examining a colleague’s work. You might be leery of a coworker who asks you to review his code. Does he lack confidence? Does he want you to do his thinking for him? “Anyone who needs his code reviewed shouldn’t be getting paid as a software developer,” scoff some review resisters.

In a healthy software engineering culture, team members engage their peers to improve the quality of their work and increase their productivity. They understand that the time they spend looking at a colleague’s work product is repaid when other team members examine their own deliverables. The best software engineers I have known actively sought out reviewers. Indeed, the input from many reviewers over their careers was part of what made these developers the best.”

From Coding Horror. This is a fun look at one way to improve your programming: asking a peer to review your code. Not in a formal way, necessarily, but in a thoughtful way that puts a different set of eyes on your code. Includes some interesting data about how peer reviews improve code, as well as a link to a new book on the subject of peer reviews. And the WTF cartoon by Thom Holwerda is priceless.

“In the past days I received several requests from my readers to suggest some CAPTCHA scripts and services quickly to embed into a web page. This post proposes a list of ten interesting scripts and services you can use to provide protection from spam bots and ensure that only humans perform certain actions.”

From Woork. This is a good canonical list. The comments include a link to a variation on CAPTCHA that I’ve seen recently, in this case, you count the number of pigs, rubber duckies, and apples when you sign in at Firepages.

“While CSS can be used to create sexy websites, writing CSS can actually be an artform by itself. The way in which CSS is created, structured, and maintained can be a thing of beauty.”

From ThinkVitamin, from a few years ago. Depending on how you learned CSS, it is fairly hard to tell if you code CSS efficiently or not. This article describes some best practices. And I intend to write an article that is more comprehensive.

“Code refactoring is not to be confused with code optimization. Code optimization is a completely different ball game, where the goal is to run the program as fast as possible by using as few CPU cycles as you can. The focus during optimization is to speed up the program, if it impedes code understandability then so be it. On the contrary refactoring may at times make your program slower, albeit most of the times by a small factor.”

From CodeDiesel. This is a pretty good discussion and series about code refactoring. The quote above in particular is useful because people confuse refactoring and optimization. It’s also a good introduction to the topic of refactoring for business people who work with or manage programmers.

“Have you ever wanted to create a simple multi-person blog, but didn’t want to bother setting up an entire WordPress installation? If so then we’ve got just the answer. By combining Twitter Search, Atom feeds, hash-tags and PHP, you can create an RSS-enabled, micro-blog using Twitter and be up and running in less than 10 minutes.”

From Think Vitamin. This is a simple and utterly brilliant way to combine several common technologies to create a publication. This is what makes internet technology so valuable. Technology both stands on its own and can be combined easily to create new value.

Jurgen Appelo has a Knol page with his list of the best software engineering books. It’s got some things old and some things new. My favorite software books tend to focus on teams, how they do and do not work well together to use software to solve problems. But his list includes a lot of books that dig into the details of software programming, for example, cryptography and regular expressions. While I would argue the rankings of individual books, there might be something here you’ve not read and would like to read.

“The user experience team members learned to speak the same language by collectively discussing our ways of working and our deliverables. This process started with the kick-off workshop, continued during the review process of the diagram and deliverables descriptions and continues to this day when we discuss how to combine smaller artifacts into project deliverables. This discussion translated into fewer misunderstandings about the contents of a document, the kind of activities expected and the required input. It increased the consistency of our work. Because each project’s deliverables were chosen from the same total set, we could reuse previous documents as examples or templates. This re-use in turn allowed us to document our work faster, leaving more time to study our design’s completeness, quality and effects on others.”

From a Feb/Mar 2005 ASIS&T Bulletin. Found through an IxDA discussion thread that includes links to a blog post by Peter Boersma and slides (see below).

While these materials are older (aren’t we all?), this is a high level but thorough discussion about how to organize then integrate standardization of information architecture deliverables within any software development organization. Since 1995, when I first was paid to do web work, the field has evolved into a vast array of job roles and specialities. While it is useful to know a little about all the roles, and how they fit together, the real challenge is to do what is described here, to integrate the roles, starting by optimizing each role. These items describe information architecture but they also apply, and evolved, into other roles.

Overall, I thought this was an excellent introduction to the problems involved in integrating the different specialities involved in creating web applications.

“The Broken Window Theory proposes the idea that if we do one bad thing in our code (i.e. break a window) then it becomes more likely that the next person who encounters that code will do something bad as well eventually leading to the degeneration of the code.

This is the same when commenting out code – if people see that there is code commented out then it becomes more acceptable for them to also comment out code and before you know it there are large chunks of code commented out and no one really knows why.”

From Mark Needham. As Mark notes, and a commenter amplifies, source control makes code comments obsolete. You have a backup of prior code in the code repository and you can revert to the prior code if your new code fails.

“Noah’s case was only the most dramatic example of a question that has long intrigued me: How do you pay employees based on performance when performance is so hard to quantify? The very idea that you can rate knowledge workers on their productivity is highly suspect and always problematic. If you mess up, the consequences are very real.

Psychologists talk about two kinds of motivation: intrinsic and extrinsic. Intrinsic motivation is what drives you to do something regardless of whether you will receive a reward. Why do you spend an hour cleaning the inside of your stove? Nobody looks in there. Your intrinsic motivation compels you to do a thorough job. We all have it — in fact, most people start out with the desire to excel at whatever they do. Extrinsic motivation is the drive to do something precisely because you expect to receive compensation, and it’s the weaker of the two.”

From Joel Spolsky, of Fog Creek Software, in his How Hard Could it Be? column at INC magazine. A summer intern came up with an idea that led Fog Creek to make a million dollars.

Actually, this problem is fairly easy to solve: equal profit participation by employees. You still have participation tiers, owners who fund the company make more than employees. But the worker bees are incented to do well if the company does well with profit and customer acquisition. You don’t really get that effect with bonuses based on performance reviews, as Spolsky points out.

“Let’s say the adoption of programming languages has very often been somewhat accidental, and the emphasis has very often been on how easy it is to implement the programming language rather than on its actual merits and features. For instance, Basic would never have surfaced because there was always a language better than Basic for that purpose. That language was Joss, which predated Basic and was beautiful. But Basic happened to be on a GE timesharing system that was done by Dartmouth, and when GE decided to franchise that, it started spreading Basic around just because it was there, not because it had any intrinsic merits whatsoever.”

From Coding Horror. If you don’t know, Alan Kay was the leader of the group that invented object-oriented programming, the graphical user interface, 3D computer graphics, and ARPANET, the predecessor of the Internet. Some great insights in this post, and links to what Kay is doing now.

My favorite line in this  post, after the quote above, “Any similarity between the above and PHP is, I’m sure, completely coincidental.” Too funny.

“In my mind, there’s really two points. One: You can take the smartest, most experienced, most connected, most brilliant people in the world and have them build the most stunningly designed and technically advanced product in the world, but if people don’t want it, then you will fail. This is roughly what happened with the Segway, for example.

Perhaps that seems a little discouraging. After all, if really smart people with all the right resources can fail, then what hope is there for the rest of us? Perhaps success is random, and maybe startups are more like the lottery than we’d like to admit.

I don’t believe that’s true though. There is an optimistic way of understanding my first point, and that’s my second point: Even if you aren’t the smartest person around, and your product is kind of ugly and broken, you can still be very successful, if you just build the right product. YouTube and MySpace are both fine examples of this.”

via Paul Buchheit: The most important thing to understand about new products and startups. Old but still excellent discussion that applies to any business, startup or existing, as well as any business and programming team. There’s a follow-on discussion at Coding Horror, I Repeat: Do Not Listen to Your Users, and another shorter comment, UsWare vs ThemWare.

I had trouble figuring out what to quote in Buchheit’s piece. For example, this quote also is excellent:

“It’s easy to find examples of this wrong attitude. When Google acquired YouTube, many people inside the company were flabbergasted, “But they have no technology!?” They didn’t understand that you only need enough technology to make the product work. Any more and you probably have the wrong priorities. I regularly see similar complaints about Facebook, MySpace, and a lot of other popular sites. Similarly, people will often complain that MySpace or even Google has “no design” or “bad design”. Again, they have enough design (or the right design) to work for their users.

So what’s the right attitude? Humility. It doesn’t matter how smart and successful and qualified you are, you simply don’t know what you’re doing. The good news is that nobody else does either, though some are foolish enough to think that they do (and that’s why you can beat them).

What is the humble approach to product design? Pay attention. Notice which things are working and which aren’t. Experiment and iterate. Question your assumptions. Remember that you are wrong about a lot of things. Watch for the signals. Lose your technical and design snobbery. Whatever works, works.”

An old post but still lots of useful things to be reminded of. All businesses, no matter how young or old, they are all startups. Either you innovate and evolve or your business dies.

“Browsers have garnered renewed scrutiny from security researchers in recent years. In 2007, computer-science students at Stanford University found a way to bypass the same-origin policy in browsers, allowing an attacker to use the browser to access data on other computers on a victim’s network. This year, researchers Robert Hansen and Jeremiah Grossman uncovered a method, known as clickjacking, of exploiting Web graphics to persuade a victim to click where an attacker wants on a page. Both issues are discussed in the security handbook.”

From SecurityFocus News. Their post includes a link to the Google handbook that includes lots of gory details about what can go wrong with web browsers.

“If you’ve ever visited the ultra-orthodox Jewish communities of Jerusalem, all of whom agree in complete and utter adherence to every iota of Jewish law, you will discover that despite general agreement on what constitutes kosher food, that you will not find a rabbi from one ultra-orthodox community who is willing to eat at the home of a rabbi from a different ultra-orthodox community. And the web designers are discovering what the Jews of Mea Shearim have known for decades: just because you all agree to follow one book doesn’t ensure compatibility, because the laws are so complex and complicated and convoluted that it’s almost impossible to understand them all well enough to avoid traps and landmines, and you’re safer just asking for the fruit plate.

Standards are a great goal, of course, but before you become a standards fanatic you have to understand that due to the failings of human beings, standards are sometimes misinterpreted, sometimes confusing and even ambiguous.”

Joel Spolsky at Joel on Software has an amusing and insightful discussion about the problem the Internet Explorer 8 browser faces in an online world with billions of web pages that will break in the browser. Even non-technical people can understand the issues involved.

URLs:

http://joelonsoftware.com/items/2008/03/17.html