Thoughts on Collaborative Planning

Entries tagged as ‘Software Engineering’

Taiichi Ohno Reinterpreted

October 24, 2009 · 6 Comments

Taiichi Ohno is credited with the creation of the Toyota just-in-time production system, and his book “Toyota Production System: Beyond Large Scale Production”  is a surprisingly good read even today when many of these principles are considered well established.

My interest was in understanding how this philosophy applies to Agile/Lean Software Development.  (more…)

Categories: Agile · Software
Tagged: , ,

26 Hints for Agile Software Development

October 1, 2009 · 4 Comments

I collect nuggets of wisdom on various topics. Recently I have been going over the topic of Agile software development; what really matters?  Below is a list of 26 key principles to guide an agile software development team.

  • Get case 1 fully working before starting case 2. Another way of saying this to use a kitchen metaphor is: “Serve the current meal before starting to cook the next“.  (more…)

Categories: Agile · Software
Tagged: ,

BPM is not Software Engineering

November 25, 2008 · 33 Comments

A lot of the confusion and difficulty in the BPM community is because some people think that BPM is a kind of Software Engineering.

Indeed, superficially it looks like Software Engineering: you start with requirements, you determine the pieces of information that need to be stored and retrieved from variables, you might have a drawing of the relationships, and in the end you have something that can be installed and executed on networked computers. But there is a difference, and that difference is the entire reason that BPM exists. (more…)

Categories: BPM · Workflow
Tagged: , , ,

Green Software?

October 22, 2008 · Leave a Comment

This post is about another one those thoughts that occur at the clashing point of several different ideas. I travel a bit, and use the laptop a lot, and it always gets HOT. Laptops today are so smart: the fan is dynamically controlled by the heat, and the heat is caused by the amount of calculations you are making at the moment. So you really notice: when you do a function that causes the computer to think, the fan suddenly picks up. It really make you mindful of when the laptop is working, and when it is “resting”. But batteries never last as long as I would like, I am always trying to think of ways to reduce the amount of processing required to do my tasks.

It seems like I am in a losing battle with Microsoft over this. Newer operating system and versions of office see me to provide ever “whizzier” ways to do the same thing. Menus used to just appear, now they have to slide down, or fade in. Often we have discussed whether this is a conspiracy between Microsoft and Intel to get us to buy faster chips and more memory, so that the new machine I have which is 100 times more powerful than the 8 year old one seems to run just about the same with today’s software as the old one did on 8 year old software. All in the name of “progress”.

Honestly speaking, we know that the advances in software are aimed at providing better usability and convenience to the user. Since you have a more powerful machine, why not use it?  The problem is that in designing such systems, we assume that CPU cycles are “free”. If you don’t use a CPU clock cycle, it is gone. But that is not really true: when you stop using the CPU cycles, the chip uses a lot less energy.

That is where “green software” comes in. We measure software on many different benchmarks. Maybe it is time that we started measuring how many CPU cycles it takes to perform certain standard operations. For example, different word processors may take different amounts of CPU time to input the exact same document.  Or they might take different amounts of CPU time to render the same web page.  Shouldn’t we, at some level, be aware of the “cost” of running such software.  To date, CPU cycles are considered so close to free that unless there is a noticeable performance hit, nobody is concerned about saving CPU cycles.  Once we become sensitive to reducing the amount of CPU time, such values could be reduced by 10x or 100x without any noticeable degradation in the use of the software.

I suppose this is all slightly ridiculous to worry about saving a few watts.  In reality the power savings might only add up to a few cents per day per laptop.  Surely there is lower hanging fruit to battle global warming.   That is true, but there is another side of it: the cost of a laptop is not the electricity, but the battery.  If software ran with 1/10 the CPU cycles, then you probably could make do with a significantly less powerful laptop, and this would generally take a lot less power.  Smaller batteries would cost less, and be less harmful to the environment.  Plus, if you are running lots of software at the same time, you could run more, in less memory, on a less powerful machine, if the software was green.

By the way, Fujitsu has a significant effort on green computer hardware.  Our servers are designed to run on less electricity than the same capability server from the competitor.  If you are running a large data center, the cost savings can be significant.  Not a sales pitch here, but simply a reflection that attention to this kind of detail is really important.

Admittedly, the time is not ripe to worry about “Green Software”.  But we should be sensitive to how much “CPU cost” a particular software product takes.  This might be something that only the most sophisticated software is willing to take on as a goal (Linux, you guys listening?)  But don’t pop my bubble: I wish to dream of a time that all the software I need runs reasonably on a laptop that does not keep getting terribly hot when all I am doing is reading and writing email!

Categories: Uncategorized
Tagged:

Agile Development – Road Trip Analogy

September 2, 2008 · 2 Comments

I needed to describe the reason that an Agile approach to software development works, and why it is not something that is isolated to the development team.  I wrote up the following explanation.  Maybe this will be helpful to you in explaining agile development to others. (more…)

Categories: Uncategorized
Tagged: ,

Rethinking the Pop-Up Dialog

July 15, 2008 · 2 Comments

The more I use windows UI, the more I believe that the concept of the “moded pop up dialog box” is not useful and unnecessary.

The “moded pop up dialog box” is a user interface technique that allows you to have a screen on display, and allow a user action to cause a new window to appear on top of it. The new window takes control. (more…)

Categories: Software
Tagged: ,

More on Disabling UI Controls

October 2, 2007 · Leave a Comment

I have been arguing for years that disabled (greyed-out) menu items and buttons are in general a bad idea because it is impossible for users to know why the associated function is not enabled at the. It is quite frustrating: the user sees a menu command that looks like it might be what is needed, but it is disabled, and there is not at all obvious why it is disabled. (more…)

Categories: Software
Tagged: ,

CFD: Content-Free Documentation

September 13, 2006 · 2 Comments

Have you ever been using a high tech product or software application, and ran across a command or prompt which you did not know, went to the help, and found a help entry, but that entry actually tells you nothing? For example, you see a menu called “XXX” and you wonder what it does, so you go to the help or the manual, and look it up. The entry says (and I quote) “In order to XXX select the XXX Menu.” This is Content Free Documentation. (more…)

Categories: Software
Tagged:

What BPM can learn from a Spreadsheet

July 9, 2006 · 14 Comments

Business office workers will never program software!or will they?

There is an interesting tension in the undercurrents of the high-tech industry. On one side you have vendors that make bold statements about the productivity that will result because all office workers will be able to make applications by themselves. On the other side you have the insider cognoscenti who chuckle at the thought of untrained people attempting to do more than the simplistic examples offered in the flashy demos. (more…)

Categories: BPM · Workflow
Tagged: , , ,

Pseudoprogramming

April 20, 2006 · Leave a Comment

What are I going to gripe about today? How about: “programmers who think they are going to make other peoples lives easier by letting them program in a new language that is less complex.”

OK, the motives are good: “Programming is complex. Many people are intimidated. Let’s make something that they will be less afraid of, and still accomplish the job.” (more…)

Categories: Software
Tagged: