Jun

10

I’ve worked with a lot of software development professionals in the last twenty years, and I’ve noticed a curious phenomenon. I think we make work harder on ourselves. It mainly seems to happen with the smarter developers, which makes it all the more puzzling to me. First, I suppose a bit of background to help understand what I’m talking about. Read more

Apr

14

AJAX and Network Performance: A Cautionary Tale

April 14, 2008 | Comments Off on AJAX and Network Performance: A Cautionary Tale

In recent years, the web has seen a proliferation of Web 2.0, or Rich Client, applications such as Google Docs. These web-browser based applications have a dynamic user interface using a technology called AJaX, for Active Javascript and XML. The user experience for these applications can rival traditional fat client applications, while at the same time, not needing to be installed and upgraded, since they’re downloaded to the browser as needed.

One of the great promises of these AJaX technologies is that of increased performance of the applications. If these applications make lots of small requests, this isn’t always the case in reality. Sometimes your performance can be significantly worse. Read more

Apr

9

Designing the Enterprise

April 9, 2008 | Comments Off on Designing the Enterprise

I’ve been thinking a lot lately about the challenges of really doing SOA for an enterprise, and some of these thoughts were crystallized by the first of a two-part paper at InfoQ called “Beyond SOA“. It’s a bit of a challenging read, at least for me anyway. They’ve got some good points, that you have to identify the business as a system of interrelating units (subsystems) and that you have to design around real-world events and real-world entities. The author also believes that even the business stakeholders have an incomplete view of the problem domain, and they’re probably right:

 “A fundamental difference exists between an enterprise operator and an enterprise designer. To illustrate, consider the two most important people in successful operation of an airplane. One is the airplane designer and the other is the airplane pilot. The designer creates an airplane that ordinary pilots can fly successfully. Is not the usual manager more a pilot than a designer? A manager runs an organization, just as a pilot runs an airplane. Success of a pilot depends on an aircraft designer who created a successful airplane. On the other hand, who designed the corporation that a manager runs? Almost never has anyone intentionally and thoughtfully designed an organization to achieve planned growth and stability. Education, in present management schools, trains operators of corporations. There is almost no attention to designing corporations.”

And I’m with him so far. Designing services for the enterprise requires an uncommonly broad view: not only how the business functions, but how the business as system should function. But from there, the author makes some surprising suggestions:

We propose a fundamental change to how we architect and design information systems, in a way that will not require business stakeholders as the primary input. We recommend utilizing a framework centered on business entity lifecycle and event-model as the primary sources of input into the architecture. Business scenarios are used only as a post-architecture fine tuning exercise, instead of the main driver.

This framework-first approach accounts for the dynamic of the business from the beginning, and is not an afterthought. It implies that the designed enterprise application is dynamically adaptive, instead of statically adaptive as it is implemented by today’s methodologies. This cuts the cost of developing and maintaining software by orders of magnitude and cut into the over 70% of IT spend that is directly linked to changing and maintaining existing systems.

and most incredibly to me

A framework-first approach capable of integrating business changes into IT implementations and providing a clear translation between business and technology could raise the success rate to close to a 100 percent. Architecting complex systems could take days instead of months or years.

I’ve dealt with producing enterprise-grade systems for years. I  believe that treating an enterprise as a set of interrelated subsystems is a worthy idea, one that is particularly challenging because of the dynamic nature of businesses and their changing environments. When was the last time that your mailing subsystem changed without you looking at the code, after all? I think however it’s cavalier to suggest that a change to this style of development, one that’s incompletely described, can result in success rates of 100% while cutting IT spend by 70%. If you can do that, then I believe you have a license to print money. Until you can prove it, I’m a skeptic.

Apr

9

Cyclomatic Complexity: Sometimes, less isn’t more?

April 9, 2008 | Comments Off on Cyclomatic Complexity: Sometimes, less isn’t more?

For quite a while now, we’ve thought that cyclomatic complexity was a pretty straightforward thing: less was better. Some recent research, covered over at InfoQ, has shown that maybe it’s not as straightforward as that.

For those who aren’t familiar, cyclomatic complexity numbers (CCNs, herein) are really pretty straightforward: they’re a measure of how many paths there are through a particular function. You start off with a natural score of one (because there’s one entry and one exit, therefore one path) and you add one for each loop or branch you encounter. They’re not a perfect measure of paths, but they do a pretty good job. There’s a close cousin which considers the nesting of control structures as well, but CCN seems to be more widely used.

For quite a while, we’ve assumed that there’s a linear relation between CCN a number of undesirable characteristics in code: fragility, bug rate, and lack of cohesion to name a few. I’m sure it probably causes sciatica as well. It’s reasonable to assume that a lower CCN is better. But here’s where it goes a little strange. According to the research

The results show that the files having a CC value of 11 had the lowest probability of being fault-prone (28%). Files with a CC value of 38 had a probability of 50% of being fault-prone. Files containing CC values of 74 and up were determined to have a 98% plus probability of being fault-prone.

So in general, you don’t want to be going out and creating functions with a CCN with a value of 400 (I’ve seen this, and no, you don’t want to know…), it appears that scores of somewhere less than the teens is not so bad.

The research isn’t without it’s critics. The scores are apparently aggregated for classes rather than the methods in them, so the results may be misleading. But it’s in intriguing result nonetheless.

The message here? If you’re using CCN as an indicator of where to look for problems (and you should be), you may want to recalibrate your radar for unnecessary complexity to be a little higher.

Mar

25

The Development Methodology Lifecycle

March 25, 2008 | Comments Off on The Development Methodology Lifecycle

I’ve been thinking lately that software development methodologies are a funny thing. In some ways, their lifecycle mirrors the very software that they produce.

There’s a phenomenon where software gathers entropy over time, sometimes called “bit rot”. Bit rot requires you to refactor your software occasionally, even regularly, tuning it up and keeping it working at its best. Without this sort of maintenance, your software has a decreased lifespan. Many refactorings focus on making things simpler, easier to understand.

As with the software that comes out of a development methodology, the methodologies themselves start out all lean and efficient, as a kernel of good ideas. Sometimes the newborn methodology is inspired by what some other methodology is perceived as doing wrong. Over time, methodologies seem to accrete all sorts of things. These are good ideas, typically, special approaches to problems, or things that people find as complimentary practices. The problem is that these become enshrined in the canon, as it were. People who have less attention to what the methodology actually says about when to use these tools, or who have less experience and can’t understand when a tool applies, begin to apply all the tools, all the time. As a result, methodologies get rather bloated, become inflexible, and eventually fall out of favor because they become too unwieldy, or at least that’s the perception people have about methodologies. I think it’s because practitioners don’t really understand when to apply the tools in question.

Read more

Mar

6

Over the years, I’ve read a fair number of Java coding standards. Very few of them, I’m going to go so far as to say “none”, really talk about what they should. That’s a pretty bold statement, so let me explain.

Many coding standards for Java talk about low-value minutiae, things like “your variables should begin with a lower case letter, and be meaningful names”, and how you should place your parenthesis. I’d like a quarter for every 30 seconds that have been wasted talking about that last point. But I digress.

The things first-generation coding standards talk about are making our code “uniform” and “acceptable”, and have been beat to death. These are also largely things that can be handled very nicely with your modern day integrated development environments, thank you very much. Renaming a field takes almost no time at all, and I can set my IDE to reformat the parenthesis just how I like, or however the project dictates they should be formatted. These standards, while they create uniform looking code, have really very little return on the time you spend creating them. What we really needed today are some coding standards that talk about more valuable things, the things that are going to save us real time and prevent errors. Think of these as graduate level coding standards. Read more

« go back

Blogroll

WP Themes