Practical Software Engineering

Well, Peter Drucker didn’t write about software management, but he did write about management. In his book Managing in a Time of Great Change he has a chapter called The Five Deadly Business Sins. Here is what Drucker has to say:

The third deadly sin is cost-driven pricing. The only thing that works is price-driven costing. Most American and practically all European companies arrive at their prices by adding up costs and then putting a profit margin on the top.

The only sound way to price is to start out with what the market is willing to pay—and thus, it must be assumed, what the competition will charge—and design to that price specification.

How does this apply to software development? Here is how I see the two scenarios in the world of software development:

Cost-Driven Pricing: A Tough Sell

In this scenario the Customer comes with the software product requirements (not quite complete, since they never are). Next the software team goes ahead and figures out how long it is going to take to build it, and tells the Customer what the expected end-date is, thus arriving at a “cost.” The Customer is almost always unhappy with the end-date that the team provides. The Customer is also unhappy with the delivered product, since the software team usually does not manage the scope at a fine-grained level. The team thinks that they know what they need to build, and proceed on building it.

Price-Driven Costing: Problem Solving with Constraints

In this scenario the Customer comes with the requirements (never complete), and a target end date in mind: an end-date that fits into the business scenario that they intend to play out. It is now up to the software team to:

1. Figure out how the product can be built under the given constraints of date and cost, and
2. Figure out how to “slice & dice” the requirements to meet the Customer’s goals.

The software team must deliver to and negotiate with the Customer regularly. To deiver the project the team have to bring their ingenuity to solve the problem.

The Bottom Line

Price-Driven Costing applies to the way software teams work. It means that we need to work back from the price (date) that the Customer is willing to take, and then we have to figure out how to deliver the project on that date. There may be times when we have to say, this cannot be done. And there will be others, many others, when we will successfully deliver the project to a happy Customer.

Do You Use Your Brain At Work? You probably have to. Knowledge workers today make up over 70% of the working population. Your productivity is your competitive advantage! Take charge of you future! I can assist you in discovering what makes you more productive, and putting you on a trajectory for greater success.

Performance, Performance, Performance! As a Software Engineering Manager, the performance of software developers is on my radar every day. I work with people like you. Call me today to help you understand and improve your or your organization’s software development performance. If you don’t call me, at least think about your performance. Today. And do something about improving it.

You are a software developer. You are good, and you know it. Maybe in the top 10%. But, do you know how good you are? Do you understand why you are so good?

Are You Ready to compete in a global knowledge economy? In the age of brainware you compete with every other brain in the world. To stay ahead of the game you must understand why you are effective and how can you become even more effective at what you do. As a knowledge worker, your brain is your greatest capital asset. Your thinking drives your performance.

If you manage people who use their brains all day it is your responsibility to enable them to work effectively. Are your daily actions helping or hurting their performance?

I decided to slack off a bit. I need some slack time to recharge my batteries. I noticed that I am not nearly as creative as I could be if I’m not rested, or if I don’t have time to think and absorb the big picture. You say you don’t have time to slack off? You are too busy? You have too many things to do? Think again.One of my favorite gurus decided to not slack off entirely, and he wrote a pretty good book on the subject. Read it the first chance you get: Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, by Tom DeMarco. Fast Company magazine asked Tom in an interview to talk about the reasons for “slacking off.”

As some of you already know, I share Tom’s point of view on many of the issues he raises. Telling people to only plan for 15 to 20 effective on-task hours per week comes as a shock at first, but then they start getting some data, and they realize that 15 might be at times too ambitious.

One idea that I have followed through the years was that I try to turn everything that I need to do into some sort of process. This allows me to free up my thinking. Once I have a process for a problem I don’t have to think about that problem again quite as much. It is not that I don’t think about it all—not unless I manage to automate it—but rather, I can concentrate on other problems, for which I don’t have a solution yet.

So, do you have a solution for slacking? If not, I urge you to figure it out how to work slacking into your regular schedule.

Links

• Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, by Tom DeMarco
• Slack Off, FastCompany Magazine, August 2001

A few months ago I came across the concept of Aspect Oriented Programming or AOP. I thought that it was interesting. And I stored the information away… somewhere. The current issue of the Communications of the ACM features a series of articles on this topic. I received my copy a few weeks ago. After the cover was staring me in the face for a while, I decided that it is time to read it.

What is AOP? Is this a new fad? I haven’t even gotten down this OOP (Object-Oriented Programming) thing—you might say—and you want to talk to me about something new already? The good news is that OOP is not going away, so don’t worry. AOP augments OOP and enables you to express certain concepts in a more powerful way.

Another piece of good news: There is a ton of information on the web about AOP. When OOP came about one had to buy books, go to must attend conferences, schmooze with other OOP enthusiasts (well this might still be necessary ) to find out more about the technology. These days you can turn to the web and learn a great deal. Start with aosd.net, the Aspect Oriented Software Development web site.

The definition of AOP from aosd.net is: “Aspect-oriented software development is a new technology for separation of concerns (SOC) in software development. The techniques of AOSD make it possible to modularize crosscutting aspects of a system.”

Before you stop reading because you think that this is yet another purely theoretical nonsense with absolutely no practical applications take a look at AspectJ. AspectJ is a seamless extension to support AOP for Java.

It is important to emphasize about AOP that it builds on existing technologies. It doesn’t work without a sound design. If you are to create a great design, you will have to apply the right technique to the right problem, be it AOP, OOP, functional decomposition, structured programming, or anything else. Remember: AOP is yet another tool into your software developer’s toolbox. If all you have is a hammer then everything will look like a nail!

Now you know that AOP exists. Go an and read about it, learn about, and write to me about it. Share your thoughts with the rest of your network.

Links

• acm.org: Association for Computing Machinery
• aosd.net: Aspect Oriented Software Development
• aspectj.org: AspectJ