SE News

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

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

For the IT profession to truly excel and flourish, IT professionals must understand how to present information in both technical and nontechnical terms. Editorial board member Wes Chou describes how to move beyond “geek think” and truly excel at serving the overall organization, from users to customers.

Wes Chou

http://www2.computer.org/plugins/dl/pdf/mags/it/2009/03/mit2009030004.pdf

Today’s enterprises know that continuous improvement of quality and productivity is a prerequisite for survival. Ever-changing market circumstances place a strong demand on agility and flexibility. Now that an increase in labor productivity has caught people’s attention again and off shoring has become the de facto mode of operation, Industrialization and Global Sourcing are key elements in the present-day IT strategy of organizations. Transforming the IT operations from a project mode to a factory mode is part of this strategy.

Hence, the Software Factory becomes more than just a metaphor, both during times of economic recession when companies wish to minimize their costs, and during periods of economic boom, when short time-to-market is essential to increase market share. From the twelve years of practical experience it has become apparent that the productivity and predictability of software solutions through a Software Factory approach have improved drastically.

The book “Managing a Software Factory” provides a complete and integral view of all aspects of a software factory. Catch words are predictability, reliability, quality and high productivity focusing on cost reduction and short time-to-market. Managing a Software Factory can be used as a guide to professionalize your ICT organization and provides a manual for setting up software factories.

Kees Kranenburg (author)

http://www.sdu.nl/catalogus/9789012128261

Party of one: Surviving the solo open source project
Tips for structuring, maintaining, and promoting your ‘part-time hobby’

With more than 100,000 open source projects hosted on SourceForge alone, starting a new one is no small undertaking, and bringing it to the masses is hardly a sure thing. In this article reprinted from Pushing Pixels, Kirill Grouchnikov explores the challenges and pitfalls of being the sole developer on an open source project. Whether you’re thinking about starting a solo development project or struggling to maintain one, get tips for structuring your development timeline, managing development priorities, and finding a niche for your project, even in the vast sea of open source software.

Kirill Grouchnikov

http://www.javaworld.com/javaworld/jw-06-2008/jw-06-oneman.html

For many enterprise architects, there is increasing pressure from CxOs to cut costs, reduce inefficiencies, and to foster agility in systems. Enterprises invest more than 70 percent of their budgets purely on maintaining their existing asset investments. This shows that there is a clear and present broken link between strategic business objectives and “keeping the lights on” in the IT department. This is verified by a recent report by AMR Research that reports that 75 percent of IT organizations have little oversight over their project portfolios and employ non-repeatable, chaotic planning processes.

By using an application portfolio management (APM) practice, IT decision makers can gain visibility into the application’s impacts that reside in the enterprise. This article describes how application portfolio management (APM) compliments an enterprise architect’s multi-faceted role. APM provides key information into the IT enterprise architect (EA) management process. It answers questions such as “Can yesterday’s applications meet tomorrow’s needs?”

Mike Walker

http://msdn2.microsoft.com/en-us/architecture/bb896054.aspx

Why won’t developers make schedules? Two reasons. One: it’s a pain in the butt. Two: nobody believes the schedule is realistic. Why go to all the trouble of working on a schedule if it’s not going to be right?

Over the last year or so at Fog Creek we’ve been developing a system that’s so easy even our grouchiest developers are willing to go along with it. And as far as we can tell, it produces extremely reliable schedules. It’s called Evidence-Based Scheduling, or EBS. You gather evidence, mostly from historical timesheet data, that you feed back into your schedules. What you get is not just one ship date: you get a confidence distribution curve, showing the probability that you will ship on any given date.

http://www.joelonsoftware.com/items/2007/10/26.html