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.

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.

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

Daniel and I got to talking again today about our favorite topic of late: what good are models in an agile environment? We reached some interesting conclusions.

We think that the process of developing a software system is in some ways inventing a new language. All the stakeholders, that is to say the developers, customers, and other interested parties, have to agree on their nouns and verbs, their common terms, which are the business concepts manipulated by the system. As we begin to identify a subset of those foundational concepts, we can they begin to form higher level constructs, such as sentences, descriptions of how the system behaves and manipulates those basic constructs. As these activities take place, the language is refined and expanded, new words are added to the vocabulary and new sentences are created, and it becomes easier and quicker to find ways to explain concepts and form yet more new sentences. This parallels nicely the way that real teams develop real systems, right down to the acceleration and growing shared understanding of the problem.

Now here’s where the modeling comes in. Just as with a natural language, we can make up our words in a meeting, and write them down on a white board, and erase them when we walk from the room, and that’s perfectly fine. We should realize that if we do that, we forgo the ability to let others learn the language as well, except from us. Further we are now required to remember the definition of every word and the nuances of every sentence. Most of us are pretty good at remembering words, but we still have dictionaries to help us out, so it’s a pretty good bet that a documented model would be useful as well.

Here’s where things start to get interesting. Companies themselves can also be modeled as systems, as can software development efforts. Development processes are also dictionaries of techniques for building software. To quote Daniel, who’s put it more succinctly than I could:

We can use the RUP (or another sufficiently-structured tome) as a dictionary to have a common language we can use to talk about how our processes are going (or not). Without that common language, it’s very hard for the team to communicate — it’s very hard for the organization to communicate to the team. It’s hard to have a discussion around what is working and what is not working. The RUP, in this case, is the common language that the industry has agreed upon that we can use to apply to create processes to solve our problems, just like we use the intermediate language with our customer to describe the problems that we can then apply solutions for. Just like the idea that we shouldn’t have a problem that our user brings us that we don’t have language for, we shouldn’t have problems with process in our software teams that we don’t have a way of describing. Not being able to describe problems in a common language prevents solutions from forming. I guess you could call it “Process Architecture”

When you think of a software development as a language, some other analogies jump out at you. Just as you wouldn’t try to write a novel using every possible word, you don’t want to use every tool and technique mentioned by every process for every project. You need to pick and choose the words and phrases (or tools and techniques) that are the correct ones to get your points across.

It’s a fairly robust analogy, I believe. I think chewing on this for a while may yield further insights for us.

Mar

5

Daniel has an interesting post on his site, What To Fix, regarding his thoughts on the role of modeling in an agile project. We’re working with some of the same people currently, so I have some insight into his points.

On one hand, people say its all emergent — put a bunch of really smart people in a room with the Product Owner and fixed time-boxes and the conversation and code will follow along naturally. I don’t think there is any denying that it’s a true statement that software can emerge from shared conversations about problems.

On the other hand, there’s the role of modeling in software development. Diagrams seem to help people understand and talk about things better, so couldn’t they be part of a conversation as well?

[Read the whole post]

I’ve had some of the same misgivings, and the same thoughts. I think that modeling in an agile environment serves more than one master. First, it allows us to visually organize our thoughts. Visual models are a very information-rich way of communicating information, you can put a lot of details into diagrams if you know the language. They’re a very efficient way to communicate thoughts.

Read more

Feb

12

This is the third in a series of posts on the fundamentals of Unified Modeling Language diagrams. The first two posts covered requirements diagrams and behavioral diagrams.

In previous posts in this series, we’ve discussed requirements diagrams (use case diagrams) and commonly used behavioral diagrams in the Unified Modeling Language (UML). This article is about the last category of diagrams: the structural diagrams, which are sometimes called static diagrams. I like to think of structural diagrams “pictures of the system standing still,” where the behavioral diagrams we already discussed are how the system behaves. Read more

Feb

12

This post over on 0×000000 talks about the newly released Firefox 2.0.0.12 being vulnerable to a security compromise, as reported by Slashdot in this article. The NoScript plugin (which you should be running, incidentally) helps with this problem, apparently.

There’s some disagreement between Ronald and the Mozilla developers as to whether this is in fact a problem, and if so, whether it’s a big one. So far, the discussions have not come to conclusion, but it’s another example of assessing risks before determining whether you should fix them, which I just wrote about. It’s funny how these things happen in groups.

Feb

12

Slashdot is running this article on a flaw found in OpenBSD’s implementation of their pseudorandom number generator (PNRG). This number generator is used by the implementation of a number of network services on OpenBSD, and from there its found its way into a number of other *NIX implementations, including Darwin/MacOS X, FreeBSD, and NetBSD. Most of the implementations other than OpenBSD have committed to fix this bug, although Apple isn’t committing to when. Knowing what “random” number is going to come up next permits some exotic exploits that allow an attacker to compromise security. The question at hand isn’t whether this fault exists, it’s how important is it.

OpenBSD’s maintainers have decided that the bug is academic, and doesn’t represent a real enough threat to fix. This puts the debate squarely into interesting territory for me. I’m a pragmatist, and I think that the development activities you perform (and this includes fixing a bug) have to be related to their real value. I classify a bug in the category of “risk”, which means I use a two-part formula to determine how important it is to address.

Although many professionals don’t realize it, risks (and this includes bugs) have two dimensions, severity and probability. Probability is frequently given short shrift, and the focus is all on it’s more glamorous relative, severity. Priority is however a factor of these two dimensions.

For example of this principle in action, we need look no further than the example at hand: the PNRG generator in OpenBSD. The argument made by the maintainers is that the probability is low enough that regardless of how severe the consequences of the exploit, the chances that it will or can be exploited are low enough that the overall priority is low. This is a questionable assumption with an open source project such as OpenBSD, and with the amount of attention that this particular bug can get.

Developers, and their subspecies crackers, are a somewhat arrogant lot (and I include myself in that bucket, before anyone gets upset). If you tell us that we can’t do something, that usually is just blood in the water. Knowing that this exploit exists, even if we have to work really hard to get to it, well, we’ll try to figure out a way anyway. This adds to the probability, simply because there are so many of us out there. Additionally, the knowledge of this weakness is easily obtained, which also lowers the barrier to entry, again increasing the probability.

There’s always the possibility that someone else will fix the problem and contribute it to the OpenBSD community, since this is open source, but if the maintainers refuse to integrate a contributed fix, that could result in a fracture of the code base, and that isn’t good for anyone.

Time is the only way that we will tell whether the OpenBSD maintainers are correct in their assessment of the probability, and thus the risk involved with this PNRG bug. If proof-of-concept or actual exploits appear for this in the wild, then the maintainers may have little choice except to integrate a fix, or to suffer people moving to other BSD variants that don’t have the same flaw.

Feb

6

The Unified Modeling Language is primarily used for describing the design of software systems, although it can be used for other purposes as well, such as business process modeling. This is the second in a series of posts covering the fundamentals of the UML, it talks about UML behavioral diagrams. The previous post covered requirements diagrams, and a subsequent post will cover UML structural diagrams. Dynamic diagrams describe the behavior of a system, the interactions that it performs in the course of doing work.

Read more

Feb

4

I’ve been intending to write an entry (perhaps more than one, don’t know yet) about the various Unified Modeling Language tools out there. At one point, I’d worked with more of these tools than anyone else I knew, and this gave me a bit of perspective on which tool was good for what particular use. Before I did that, I thought that it would be a good idea to do a few posts on the UML itself: what it is, why you care, and how you use it. This post covers the requirements model and diagrams, one of three broad categories of diagrams in the UML, the others being static and dynamic diagrams.

Read more

keep looking »

Blogroll

WP Themes