SE News

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

Het testen van software en systemen heeft zich een volwaardige plaats in het traject van ontwerpen en bouwen van systemen verworven. Het besef dat hoe vroeger een fout wordt ontdekt, hoe makkelijker en goedkoper het herstel ervan is, heeft daar in belangrijke mate aan bijgedragen.

http://www.informatie.nl/Artikelen/2009/december/

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/

The free lunch is over. Multicore processors are not just coming—they’re here. Leveraging multiple cores requires writing scalable parallel programs, which is incredibly hard.

Tools such as fork/join frameworks based on work-stealing algorithms make the task easier, but it still takes a fair bit of expertise and tuning.

Bulk-data APIs such as parallel arrays allow computations to be expressed in terms of higher-level, SQL-like operations (e.g., filter, map, and reduce) which can be mapped automatically onto the fork-join paradigm.

Working with parallel arrays in Java, unfortunately, requires lots of boilerplate code to solve even simple problems. Closures can eliminate that boilerplate. It’s time to add them to Java.

Mark Reinhold

http://blogs.sun.com/mr/entry/closures

I have never written a bad line of code.

When I tell people that, they often scoff and offer replies like “so you’re not a programmer then?” and “let me guess, you’re a coding deity or something?” Well let me say, I am a programmer and I am not Codethulu, but in the same manner that Al Gore can fly around the world in a private jet without polluting, I have negated my bad code footprint through the purchase of Bad Code Offsets.

Alex Papadimoulis

http://thedailywtf.com/Articles/Introducing-Bad-Code-Offsets.aspx

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