Jun

19

Why is it so difficult to get people to collaborate? When coaching agile projects, we always advocate that people collaborate rather than try to find ways to avoid talking to one another, such as by writing documents and making people read them.

The development teams are usually all over this. They want to collaborate with people who they need things from, such as the business owner in order to better understand the requirements. They’d rather just ask questions of a live body than read a document. Oh, sure, occasionally at first they don’t really want to talk to “those other people,” developers do tend to be introverts after all.  Usually once they try it they think it’s much better than the old ways.

Why, then, is it so hard to get the developers to collaborate with people who want the things they produce? I’m thinking specifically here about the usual suspects, I suppose, the database organization, the testing organization, and any sort of compliance/oversight organization. These are the same organizations who usually have a dim view of agile to begin with, for reasons I’ve talked about before. Why is it so hard to convince an development team (and I’m intentionally not saying a ‘project team’ because they don’t have all the right people) to invite someone, such as a tester, to one of their meetings, when in turn they want to be part of requirements meetings?

You could be forgiven for thinking that once they’d seen the value of working collaboratively, rather than focusing on documents and hand-offs, they’d naturally want to start doing more of it, extending that approach to people down stream from them in the development process. Strangely, that doesn’t seem to be the truth, I get a great amount of pushback when I suggest this type of thing.

I don’t think this is a case of “you should change, but I don’t need to,” since the developers are  already changing the way that they work. To me, a more compelling explanation is that they don’t want to confront someone who may be hostile to the way that they’re working. This is probably particularly hard when they’re new to agile, and they’re not used to working this way yet. But you’d think that having seen the advantages, and wanting to maximize the amount of work not done, they’d push the envelope more than they seem willing to.

Even more surprising is when it’s suggested, I get pushback on collaborating! “We don’t want to waste their time,” they tell me, or “It’s not their meeting, it’s ours.”

I guess life is just full of people behaving in ways that seem harmful to themselves, and that surprises me.

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

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

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

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

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

Blogroll

WP Themes