Insomnia Consulting.com

First, I had been formulating some thoughts on “learning” to be a software professional before I read the following two posts.

Software Professionalism by Sarah George
Followup to Software Professionalism by Edward Nilges

My thoughts were based on conversations I had with my boss and a consortium of folks who want to explore what might make the Pittsburgh region more competitive in the Global Software Development Marketplace (i.e., competitive against offshoring).

The first topic I’d like to address is whether the the SoftWare Engineering Body of Knowledge (SWEBOK) is a useful heuristic to evaluate the types of education / training one must receive to be a competent software developer.

I’ll start with the positive aspects:

1. It provides a central repository for knowledge. The document that describes what SWEBOK is is not the same as the “Body of Knowledge”. Like many professional disciplines, a body of knowledge is a canonical thing that isn’t necessarily codified anywhere, but instead represents what a “knowledgeable” professional should mostly know to be regarded as competent.
2. It presents an opportunity to license software developers using a standard set of knowledge. While there are many arguments against licensing, I feel that Nilges blog entry provides a compelling argument for licensing.
3. It provides a foundation for future amendments.

There are many dissenters voicing opinions. But I believe the most alarming comment comes from Martin Fowler on his Bliki in that he suggests that a flawed SWEBOK could indicate that a developer performing non-SWEBOK approved tasks might be legally susceptible.

Cem Kaner wrote a thorough statement prior to the 2003 review here where indicates problems withe SWEBOK’s content and the review process.

Keith Ray summarizes many concerns in his post here

The fundamental argument is that those people authoring the SWEBOK might have gotten it wrong and that not enough people contributed to the authoring / review to ensure that it encompasses a “real” body of knowledge.

A poorly stated SWEBOK has, as Fowler stated, legal ramifications. But also, the perception of consumers of Software Development services and educational institutions stands to suffer significant negative effects as a result of mis-guided devotees of “this” version of the SWEBOK.

Should we throw the baby out with the bathwater?

A more constructive approach might be to use a continual peer review process.

Some practices that might help that cause would be to begin incorporating what each individual knows in a matrix of “complete” software development knowledge. Or to encourage feedback from educational institutions and corporations on what is being taught to young software engineers, and how applicable that is to the vocational practice of software engineering.

The second suggestion is where my interest in learning stems from. It seems that a college education cannot in itself prepare a software engineer for success in the corporate environment.

This is not because of any fundamental failing of education (after all it serves other professions perfectly well). More accurately, the SWEBOK is evolving at such a pace, and is fragmented by so many competing theories and technologies that it is only when the knowledge learned in school is applied to a certain problem that a grasp of the relevant aspects of SWEBOK can be applied.

This implies that a competent vocational programmer is not truly abreast of the entire SWEBOK. That’s fine. Physicians don’t know all diagnoses and cures; Lawyers don’t know all law; Engineers specialize in specific fields. However, by understanding where the gaps in our knowledge are compared to the whole, we’ll be able to direct learning to specific vocations, specialities, or technologies and give software professionals a more likely chance that they’ll be able to target their learning. At the same time, employers will be able to understand what “types” of developers they require, and what the specific attributes are that match those developers with their particular environment.

Enterprise Business Modeling, Sinan Alhir

This discussion was a little higher-level than I hoped. I was anticipating a discussion on how to create an inclusive model of all the business processes in an organization.

Instead Sinan developed a model for describing the “reliability” of the interfaces between departments as a way of gauging the “health” of an organization.

However, in the end I was impressed, because from an organization perspective (even dropping the definition of organization to a single IT department) it provided a well known model of measuring effectiveness.

At our organization, we spend a lot of time deciding which kind of metrics are important to show whether we are doing a good job. Since our organization supports manufacturing, Sinan technique, taken from Industrial Engineering, is a perfect complement.

How to talk to a Project Manager

Was hoping for a more thorough discussion of all the touch-points where a dev team needs to provide appropriate documentation to satisfy traditional (PMI) project managers. Mostly just got a discussion a about requirements and risk management. Still insightful though.

And I won a book on Six-sigma project mgmt; which should impress my boss;’)

Keynote : Model Driven Development

This was the first “pro” UML talk I had heard. Admitting there had been some problems with UML, but promising that MDA, by way of UML models, was the “new” way to develop software, Brian Selic made some promising observations about the future of software development using more high level languages.

I still wonder if these need to be graphcal, of if text based languages written at a higher level of abstraction could do the same thing.

Either way, the thought that higher level of abstractions are not possible without getting domain specific still gets in the way.

Brian, however, pointed out some common problems (thread concurrency, memory mgmt) that could be resolved by higher levels of abstraction. So maybe, as Juha pointed out, we won’t get the 40x production improvement. But maybe a 1, or 2x improvement is still worth it.

SOA and UML

Another pro-UML talk. Not much about SOA, but a lot about using “pragmatic” UML. Basically a demonstration of Sequence, Class, Package and Activity diagrams to model a system.

The problem I have with this, is that I don’t think a loose interpretation (which is what most people are doing) is going to be enough for the tools vendors (and MDA). So from my perspective, it’s learn formal UML, or don’t benefit from MDA. Can/Will organizations support the training this early. Probably not until a middle/late adoption a few years off.

However, this speaker also showed some of the work by OAG and OASIS. Both groups have distributed pre-designed UML diagrams of “patterns”. A great way to re-use models and “jump-start” development where frameworks either don’t exist, or are too heavyweight for the problem.

Also a great demonstration of how modeling (even not MDA) can benefit an organization. For example, several organizations I’ve worked for had hoped to create a reusable component library, or framework. However, just having models which would provide a reusable implementation guide would have solved the majority of their problems.

Architecting Systems with Patterns

This one was way over my head. A discussion of patterns (mostly for embedded/realtime systems) upon which to base an architecture.

I love patterns, but discussing this, this late in the day was beyond me. Hopefully it will provide some motivation to look into patterns more relevant to my work, however.

More tomorrow…

Upon reading Karl Wiegers’ article in the June ‘05 issue of _Software Development_ (Wiegers, Karl; “…Are We There Yet?”; June 2005, pp26 - 29) it occurred to me that it’s impossible to predict, with 100% certainly, the date software will be ready for delivery.

I’ll call this (assuming no one has claimed this already) Greg’s Uncertainty principle.

Wiegers’ article describes methods for judging release criteria and progress towards release criteria. An underlying theme is that a team can judge how many defect might be present, but can never tell exactly how many are present.

So, assuming your team keeps good history, you can extrapolate (based on project size and complexity) how much time and effort a project will take). The unknown, is how many defects will exist.

So here I am, working at 7:00PM on a Sunday with a Monday deadline. What if I find 1 bug that takes more than 12 hours to resolve? It’s possible; and would kill my deadline. 1 bug… What are the chances?

“Phase II” of our software project has started.

First, Phase II is a funny way to describe a second iteration when you don’t really have iterative development. In a shop that still believes in the waterfall method; this is the only way you can get working software before a clueless manager decides to start the analysis paralysis.

The customer asks (rightly so): Why Phase II? Because he is being asked for more money to fix things IT didn’t get right the first time.

One one hand… the customer is right. It views IT as a service oriented organization (like a consulting company) that can simply pony up some free development if the first “Phase” didn’t go quite as planned. But, as I discuss with my clients, it doesn’t really matter who made the mistake. It’s still going to take some time to perform the “fix”. Of couse, in consulting, you’ve got some investment in the client; and it’s worth taking a hit to satisfy/retain said customer.

Of course, it’s even more worth it in internal IT organizations. Only you don’t get the opportunity to recoup costs by over-billing later on; or pulling the profit from the project to cover rampant expenses.

The client in this case is asking more than the IT manager can deliver.

The “real” solution is for the IT organization to keep evolving solutions until they are right; without pretending like the customer is paying more, or less, for true iterative development.

Only IT can’t do that because there are too many small projects, and they need tight schedules more than anyone to deal with that fundamental strategic flaw. Even though many IT managers will claim the customers are badgering them on schedules, that’s just another way of pointing fingers.

A “good” IT development arm should limit their efforts to more broadly scoped applications that can encompass many requests in the name of evolution; rather than as separate projects. A project would never be “finished”. But the cost of maintaining an unnecessarily complex project portfolio would be mitigated. And staff could focus more on aggressively approving a few core applications instead of haphazardly patching applications in a race to overcome a unmanageable work backlog.

No more phony Phase IIs.. Only constant quality improvement.

I had been thinking alot (and blogged a little yesterday) about cooperative models of business. This line of thinking had come from earlier readings (sorry can’t remember the links) on “non zero sum game theory” and “gift cultures”

“Laurent Bossavit”:http://bossavit.com/thoughts/archives/000811.html has an excellent summary of game theory that gets straight to the point.

The other thing I thought about last night after working on a “draft” blog is that IT departments suffer from expectations about how other business groups manage projects. The problem might be that most other business departments don’t actually do project management; and for most companies upper management has little concept about how more complicated projects should be developed?

I need to get more feedback on that last point. It seems superficially useful; but I’m not sure how accurate it is.

And I’m not trivializing what other business units do. But the nature of a IT project is more like R&D combined with product delivery. This is a very difficult thing to do in any “true” engineering field. Think about when we create analogies to building structures… What we really mean is doing engineering after the R&D work has already been done. There are a limited amount of customizations that can be asked for by the customer; so the information gathering can be more targeted.

So if a prototype is more like the R&D; and the final delivery is defining “customizations” based on a prototype… What does that solve? The people that wrote the prototype are more experienced with the problem space and can minimize risk for the final delivery.

But we don’t have time to prototype, you say? What if business isn’t asking for dates because the date is important, but because they want to plan business better. Does 1 extra month matter in those instances?

And what if we take a more proactive view to developing for our enterprise customes? Could we speculate the “types” of applications they might want. And begin writing prototypes ahead of time? Or reuse prototypes that are architected to fit less-specialized situations?

Today is a perfect example of why overtime is bad.

Early in my current project I suggested that our deadline was unrealistic.

Three options:

1. Change the deadline
2. Bring in more resources (Sorry Mr. Brooks)
3. Drop features.

Better, Faster, Cheaper… Pick two.

Schedule was non-negotiable; despite not being tied to any specific business event other than “That’s when the customer wants it”. More resources wasn’t going to work because

1. we didn’t have any; and
2. I couldn’t have assimilated resources in to the project in such a short timeframe.
3. All the features were “required” in the first release.

(Update… Read this blog for more thoughts on adding people to “speed up” a project )

Overtime stems from un-expected schedule constraints (Parkinson’s Law + Murphy’s Law is interesting here)

Standard PMBOK would insist on scheduling risky activities early in the project, stemming the need for overtime late in the project. But the real point is that folks need to work at a sustainable pace. Anything greater than that is inserting additional risk in a project.

This guy talks about the differences. This is a good read in itself.

However, if I continue along my thinking that we need to satisfy the (often un-realistic) expectations of busines unit managers, it doesn’t matter much.

Here’s the dialog:

BU Mgr: When will the project be finished?
IT Mgr: It depends… This project is “different”. We have risks we have to manage including the fact that we’re iteratively gathering requirements from your users.
BU Mgr: OK, I understand if the requirements change, but I think that my employees know exactly what they want.
BU Mgr: So when will it be ready?
IT Mgr: (Sighs deeply and gives arbitrary date)

So three options (that Johanna Rothman advocates here)

• Explain schedule dates with confidence ranges, especially if you’re not using an iterative lifecycle.
• Use an iterative lifecycle and explain what you’ll implement with confidence ranges. (”We can do these ten features, and maybe these other three in the next month. We’ll let you know before the end of the month.”)
• Measure more than just the date of the project. I’ve discussed single-dimension measurements, especially just date measurements before. They’re poison to seeing the true project status.

I like these.. Though I think they all rely working with well-educated users; which we haven’t been aggressive enough in creating. And it’s tough to explain these issues, when a manager blind-sides you with the “schedule” question.

I had hoped to make a post on Eclipse development. Especially building and automated testing. However, in the meantime, I got pulled back into a Struts web application that I worked on previously.

While waiting for my unnecessarily long builds to run (more learning through mistakes;’) I have been reading up on processes and trying to get some more exposure to how agile, in general, compares to agile for software development.

Queue theory, value flow, the theory of constraints, etc… all factor heavily lean manufacturing. But many of those topics are far from the minds of most software developers.

Aren’t we delivering value just like any “manufacturing” plant? Shouldn’t we consider what we can do to both measure that output and improve our throughput?

Having just given some general talks on Test Driven Design, I feel the need to “refactor” my presentation.

Because the last presentation (May 16th at Pittsburgh Java User Group) was poorly attended, I assume the topic, or subject matter, may have been mis-represented.

In retrospective, the areas discussed (unit testing, integration testing, refactoring) have all been discussed under the umbrella of Test Driven Design. And while my talk was supposed to be more about the “philosophy” of Test Driven Design, I think that

a) it wasn’t obvious from the presentation title, and
b) I didn’t do a good job presenting the intended subject matter either.

A couple days ago, Jeff Langr posted this

One point he makes is that teaching a programmer to recognize refactoring opportunities and teaching them how to react appropriately (perform the “correct” refactoring) is diffficult.

A possibility, then, is to redo my presentation so that it focuses on that particular problem.

Another possibility is to create a list of programming defects and write testing patterns that will help prevent/expose those defects.

Java Testing Patterns appears to address different types of testing, but not the types of tests that should accompany various code patterns. I’m thinking that given certain bugs, or Java puzzlers (from the book of the same name), or certain patterns there should be certain tests that expose / reflect those design decisions (or lack thereof).

Two years ago, this post by Mary Poppendieck, caught my eye. The article requires membership to the group, but a quick summary is simply “Any department’s value should be determined by it’s contribution to shareholder value”.

Read the rest of this entry »