Yeah that bothers me too, especially as many of the people who rail against xDD and agile haven’t taken the time to get the understanding necessary to comment.

“Successful software development existed prior to any of the xDD methodologies that are all the rage in certain current circles.”

I’ve been writing software for 18 years. Expectations for software keep getting higher. xDD it’s an appropriate adaptation that has been made to meet expectations.

I can still choose to use the techniques I used 5 or 10 years ago, but I wouldn’t be as effective.

There is indeed a “rage” in play, but it’s not an aspect of folks practiced in xDD. It’s part of teh perspective of folks who are looking in from the outside. It’s their emotional content in regards to xDD.

It’s a response the the lethargy that has grown around software in the past five years, making stuff like xDD seem revolutionary rather than merely evolutionary. For folks who have kept abreast of the changes and who haven’t come under the influence of the lethargy, these changes have indeed been logical, small steps forward.

From the perspective of folks who are now only becoming aware of an entire new field of software development, xDD can appear to be all the rage. It’s an unfortunate side effect of market influencers that don’t have the capital, the volition, or even the permission to adapt evolutionarily, and who work hard to keep their constituents from out-pacing them.

Many of us started down this path almost 10 years ago. We certainly don’t see this as anything akin to a rage. We’re just following the continual, slow and steady path of continuous improvement, just as we always have.

I do feel rage in regard to the entitlement to remain increasingly resistant to change as even more change gets delayed. The more change that piles up, the greater the resistance that is growing in the people who have barely just begun.

xDD ideas have merely consolidated values, principles and practices. They aren’t new. Maybe successful software development do exist without these underlying ideas, but I haven’t seen any yet. I find it easier to call out principles than leave them unspoken and tacit.

Why the assumption that those are the only two possibilities. Successful software development existed prior to any of the xDD methodologies that are all the rage in certain current circles.

You’ve defined the roles uniquely enough, but I think you’ve made a mistake interpreting the uniqueness of the roles as unique human profiles.

Few engineers or developers are not a blend of both – among other – profiles.

Ever seen engineering companies led by accountants or sales people?

HIPA regulations is supposed to protect us from these security holes in an organization already. If that organization chooses to protect themselves from violating HIPA by using certification requirements during hiring seems reasonable, but to make it an industry wide requirement to even work in that field of software or to put liability on the engineer is ludicrous.

The liability lies with the company/agency who works for them (unless he is the company). IMO alot of these security issues would be better mitigated if entities faced real repercussions for violating the existing regulations.

Certianly anywhere you find a fiduciary duty mandate special considerations apply. As mentioned above, IEEE certifications usually apply wherever a government agency is concerened – obviously this wasn’t enough for the Veterans Administration. IMO the whole process should be specially subject to certification where the compromise of security or identity is in question.

@bogardj, et-al
Software “Engineering” is more akin to permanent r&d work in other engineering professions. The inputs/outputs fluctuate from project to project (And with-in the same project) to much for it be otherwise. I don’t see this ever changing; otherwise it wouldn’t be software.

The difference, as I see it, between Programmer and Engineer in our profession is merely how far ahead the two look. An Engineer looks towards the future issues of a project (maintinance, cost of ownership, etc) and factors that into his solutions for today, while a Programmer just looks at the problem at hand.

Developer and Engineer are synonymous in this industry because both do the same thing (mostly). The confusion comes from giving both titles to programmers (AKA code-monkey) as well.

Also, a clarification. Most engineering professions have licensing programs, but very few are any more required then software certification in this market. Civil Engineering and Structural Engineering are their own little worlds as most of the work is for the public sector and we all know how Beauracrats are…