SE News

Most data visualization on the web consists of static images. Typical interactive visualizations use Flash or Java, both of which have drawbacks and require plugins, don’t work on mobile devices, etc. A number of recent visualization tools based on JavaScript promise to finally bring visualization to life on the web. The ways they work differ, but they all profit from recent advances in JavaScript performance across all modern browsers.

Robert Kosara

http://eagereyes.org/blog/2010/javascript-key-to-in-browser-visualization

It’s time for IE6 to die. Seriously. The funeral’s been arranged for March 1st, yet about 20% of the web still use this wretched browser.

Internet Explorer Six, resident of the interwebs for over 8 years, died the morning of March 1, 2010 in Mountain View, California, as a result of a workplace injury sustained at the headquarters of Google, Inc. Internet Explorer Six, known to friends and family as “IE6,” is survived by son Internet Explorer Seven, and grand-daughter Internet Explorer Eight.

As much as I’d like March 1st to be the last day that people browser the web with this browser, that’s not how it’s going to be. Despite being horribly out of date, people still use it.

Adrian Kingsley-Hughes

http://blogs.zdnet.com/hardware/?p=7480&tag=wrapper;col1

This article presents some common behaviors I’ve observed from my past few years of interactions with geeks, nerds, and other highly-smart technical people. For brevity, I will simply use the term “geek” throughout this article as a catch-all term for such people. I don’t mean to pass any value judgments on people who exhibit such behaviors; these are simply my observations and personal theories for why these behaviors occur.

Philip Guo

http://www.stanford.edu/~pgbovine/geek-behaviors.htm

This installment of Evolutionary architecture and emergent design tackles a variety of topics related to evolutionary architecture, including the important distinction between design and architecture (and how to tell them apart), some issues that come up when you create enterprise-level architecture, and the difference between static and dynamic typing in service-oriented architectures. This installment rectifies the lack of material about agile architecture.

Neal Ford

http://www.ibm.com/developerworks/java/library/j-eaed10

The rate at which power-management features have evolved is nothing short of amazing. Today almost every size and class of computer system, from the smallest sensors and handheld devices to the “big iron” servers in data centers, offers a myriad of features for reducing, metering, and capping power consumption. Without these features, fan noise would dominate the office ambience, and untethered laptops would remain usable for only a few short hours (and then only if one could handle the heat), while data-center power and cooling costs and capacity would become unmanageable.

As much as we might think of power-management features as being synonymous with hardware, software’s role in the efficiency of the overall system has become undeniable. Although the notion of “software power efficiency” may seem justifiably strange (as software doesn’t directly consume power), the salient part is really the way in which software interacts with power-consuming system resources, [and how it can] contribute to (or undermine) overall system efficiency.

Eric Saxe

http://queue.acm.org/detail.cfm?id=1698225

Cloud computing allows companies to store and process data more efficiently than ever. But the code that’s used to control the machines in a computing “cloud” remains surprisingly clunky. Now some researchers are exploring novel programming languages for controlling the cloud, and they’re borrowing an approach developed in the ’80s.

Most programming languages were never designed handle so many computers or so much data spread out across them. Software frameworks such as Google’s MapReduce and an open competitor called Hadoop provide handy tools for doing this. But there’s room to make the process much more efficient.

Erica Naone

http://www.technologyreview.com/computing/24220/

I had to work late and my manager supported by staying late with me. If he was somewhat technical, he could have asked relevant questions or maybe even offered helpful suggestions. But he hadn’t written code in years – and never in the language I was using. He just slowed me down.

I’m now a manager for a team of developers. It’s getting late one afternoon and a customer calls me up and starts yelling in my ear. Some system we sold them was down and they had to produce reports by the following morning or there would be hell to pay.

Of course I stayed late with my developer to solve this customers’ problem. And guess what? Yep, I hadn’t coded in years and never in the language he had to work with. So I could offer very little in the way of technical guidance.

When a manager tells his developers to work late, should he stay late too?

Eric Spiegel

http://itmanagement.earthweb.com/article.php/3854421/When-Developers-Work-Late-Should-Manager-Stay-or-Go.htm

Ward Cunningham coined the metaphor of technical debt in 1992. “Shipping first-time code is like going into debt,” he said. “A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid.”

For large software projects, using debt is often a wise financial strategy. But incurring debt is always a risk, especially if it is high-interest debt and you’re not paying close attention to the cost. The same is true of technical debt, and it applies not only to code but also to architectural design and even to requirements analysis.

What is your project’s analysis debt load? What’s the difference between good and bad analysis debt? What are causes and remedies for such debt? Mary Gorman and Ellen Gottesdiener explore the concept of analysis debt and consider strategies for prudent investing.

Mary Gorman/Ellen Gottesdiener

http://www.stickyminds.com/s.asp?F=S15549_ART_2

At the end of the day, it’s not whether you’re following one process or another that matters, but whether your approach successfully delivers software that people like using—and a process you and your team likes.

Different processes describe different practices to adopt and use. Many tests for good process usually assess whether you’re following the process or not, which doesn’t necessarily mean you’re delivering software people like or that you prefer to work that way.

So, to perform a quick properties-based health check on your current approach, grab a group of your team members, sit down together in a room, and discuss these properties. For each property, ask the team to rate it on a scale of one to five—five meaning you’ve got lots of that property, one meaning that property doesn’t exist for your group at all. Sometimes I use grade levels A through F. Then when looking across properties, I come up with a handy report card.

Jeff Patton

http://www.stickyminds.com/s.asp?F=S15474_COL_2

When the Sarbanes-Oxley Act (”SOX”) was passed in the wake of Enron and other examples of bad business behavior, I (…) [speculated] that maybe–just maybe–this legislation would elevate that status of testing in the corporation. After all, if corporate officers and directors had to accept potential liability for errors or omissions, they might look at testing as more of a necessity and less of a luxury. What a breakthrough that would be, from the bowels of IT to the rarefied air of mahogany row!

It may be coming true. In the past year, I have experienced more than one instance of corporate audit and compliance inserting itself into the testing area and vice versa. This is unprecedented in my experience and may portend the anointing of testing as the new accounting of IT.

Linda Hayes

http://www.stickyminds.com/s.asp?F=S15592_COL_2

When it comes to user interface documentation, wireframes have long been the tool of choice. However, using traditional diagramming tools like Visio, OmniGraffle, and InDesign, most wireframes today look the same as their ancestors did from a decade ago – assembled with rigid, computer-drawn boxes, lines and text. While these artifacts have served us well, they can also be slow to produce, burdened with unnecessary detail and give a false impression of “completion.”

To compensate for the drawbacks of traditional wireframes, many practitioners put aside the computer in favor of simple pencil sketches or whiteboard drawings. This speeds up the ideation process, but doesn’t always produce presentable or maintainable documentation.

There is a growing popularity toward something in the middle: Computer-based sketchy wireframes. These allow computer wireframes to look more like quick, hand-drawn sketches while retaining the reusability and polish that we expect from digital artifacts.

Aaron Travis

http://www.boxesandarrows.com/view/sketchy-wireframes

How many times have we all run across a situation where the performance tests on a piece of software pass with flying colors on the test systems only to see the software exhibit poor performance characteristics when the software is deployed in production?

A lot of time is wasted on verifying(and re-verifying) the validity of the test, checking for hardware/network differences, checking hundreds of parameters on the test systems versus production in the hopes of finding a meaningful difference.

By far the biggest reason I have seen for the performance discrepancy above is not due to a faulty test but due to the stress test being executed on wildly different data sets than what is in production. The data sets between production and test systems in many cases are an orders of magnitude different in size and richness.

Ashish Soni

http://saasinterrupted.com/2009/12/16/the-most-common-flaw-in-software-performance-testing/

This month’s column is simply a collection of what I consider to be facts—truths, if you will—about software engineering. I’m presenting this software engineering laundry list because far too many people who call themselves software engineers, or computer scientists, or programmers, or whatever nom du jour you prefer, either aren’t familiar with these facts or have forgotten them.

I don’t expect you to agree with all these facts; some of them might even upset you. Great! Then we can begin a dialog about which facts really are facts and which are merely figments of my vivid loyal opposition imagination! Enough preliminaries. Here are the most frequently forgotten fundamental facts about software engineering. Some are of vital importance—we forget them at considerable risk.

Robert L. Glass

http://www.computer.org/portal/web/buildyourcareer/fa035

Many approaches to object oriented modeling tend not to scale well when the applications grow in size and complexity. Context Mapping is a general purpose technique, part of the Domain Driven Design (DDD) toolkit, helps the architects and developers manage the many types of complexity they face in software development projects. Different from other well known DDD patterns, context mapping applies to any kind of software development scenario and provides a high level view that might help the developers to take strategic decisions, like whether to go for a full scale DDD implementation or not in their specific project environment.

We’ll explore the many sides of bounded contexts and how to use them in building a context map to support key decisions in a software development project.

Alberto Brandolini

http://www.infoq.com/articles/ddd-contextmapping

Michael Poulin elaborates on the differences between of governance and management and tries to explore the ‘wonderland’ of governance in a service-oriented environment. He defines SOA Governance, explores the relationship between governance and enterprise architecture, and discusses accountability and ownership of governance efforts, and how practitioners can instrument SOA governance.

Michael Poulin

http://www.infoq.com/articles/poulin-wonderland-soa-governance