Even when you’ve done something many times before, sometimes you forget something or make a mistake.
This morning I was on my way to visit a client and realized I’d forgotten something. It seemed to me important enough to do something about it, so I went back home and got it. The unanticipated delay threw my schedule into disarray. I wasn’t going to arrive by the time I wanted. I was frustrated and unhappy with myself.
I see similar things happen all the time in software development projects. Something throws off the schedule. People get unhappy. Read More
My article, Taking the Long View in Software Development, has been published on ProjectManagement.com. Free registration is required on that site.
I’ve been an advocate of using feature teams instead of component teams for a long time. Back in the 1980s and 1990s, when I was working on embedded systems using 8-bit microprocessors, I often did both the hardware and software development. The easiest way I found to work was to develop both in parallel, adding complete functionality feature by feature. Working in this fashion also gave me great insight into choosing whether to implement a particular bit of logic in the hardware or software. Sometimes a software implementation could save a lot of expensive hardware, and other times a small bit of hardware could save a lot of software or provide better performance. Since I was working on both sides of the fence, I could easily move the logic from one to the other, sometimes changing my mind as I learned new information while implementing the functionality.
When working in larger teams, the work was usually split between hardware engineers and programmers. Occasionally I could influence a change in the hardware while working as a programmer, but not always. I really missed the ability to optimize across the hardware/software interface that I’d had when doing both sides.
When you scale up to large numbers of people working on a system, things can get out of hand, though. What happens when a lot of people make changes to the same components without talking with each other? Usually, the conceptual integrity goes out the window. So, what to do? Read More
Ward Cunningham originally coined the term Technical Debt and described it at OOPSLA 1992
“Shipping first time code is like going into debt. 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. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”
In this, Ward was not referring to poor programming practices, Read More
Everybody wants to get full value for their money. I can pinch a penny as hard as the next guy, maybe harder. But I’ve learned in many ways and many contexts, the very things I do to get more for my money, often result in actually getting less. How can this happen? Read More
My good friend, Steven M Smith, tweeted
AGILE methods emphasize realizing short-term OBJECTIVES rather than creating long-term objectives and trying to satisfy them.
I completely disagree with this statement. I don’t agree that short terms objectives are the emphasis in Agile methods and I don’t agree that short term objectives are preferred over long-term objectives. I think that Steve’s misunderstanding is rooted in the fact that he has only read about Agile methods, and not practiced them. I think that it is impossible to get a deep understanding of Agile methods by reading without experiencing. Therefore, I’d like to encourage Steve and others talking about Agile methods to try to get some experience before making such statements. I’d also like to offer an explanation that attempts to clear up this particular misunderstanding. Read More
David Maister asks, in a business turndown, do you respond with cost-cutting measures, such as layoffs of junior personnel, or do you reduce the profitability at the top, redirecting the efforts of your top people to long-term growth while the junior people attend to the reduced amount of immediate work? As he says,
As always, I have to stress that this is not a moral issue but one of pragmatics.
As I read through the comments on this post, I came across one that noted this was a case of
The classic fight between short-term “success” and long-term prosperity.
Suddenly I was struck by the parallels between this dilemma faced by business owners and those faced by software developers. Read More
Esther Schindler, a senior editor and columnist at CIO.com, recently asked on the agile-testing yahoogroup,
If you could get the (client) boss(es) to understand JUST ONE THING about computer consulting and contracting, what would it be?
It would be that software development is not a commodity. The cost-value equation is not just enhanced by cutting costs, but more effectively, by enhancing value. It’s not just a matter that software is produced, but what software is produced. Does that software clearly express the nature of the business? Is it an asset that can be extended and adapted as the business grows and changes? All too often, the only measure applied seems to be the hourly cost of the software production (neglecting even the number of hours required). Too often I get the feeling that I, the consultant, pay more attention to the long-term value to the company than do the employees and executives of the company. Read More