Fear in Software Development

In software development, fear is what drives much of the smoke-screening and mirroring that occurs. These tactics have lots of names like “CYA” (Cover Your Ass), or the generic “politics,” and they all negatively effect the development of software. Software development is primarily about figuring out what the hell it is the customer wants implemented, and then how to implement it, both code- and schedule-wise. Put broadly, software development is figuring out unknowns or, as they say, solving problems. It’s hard to solve problems when the set of positive data and other inputs you have is filtered and limited.

If it’s true that the negative stuff above is caused primarily by fear then, it’d be handy to know what those fears are so you can address them. Here’s a list from

Planning Extreme Programming
:

Customers are afraid that:

  • They won’t get what they asked for.
  • They’ll ask for the wrong thing.
  • They’ll pay too much for too little.
  • They must surrender control of their career to techies who don’t care.
  • They won’t ever see a meaningful plan.
  • The plans they do see will be fairy tales.
  • They won’t know what’s going on.
  • They’ll be held to their first decisions and won’t be able to react to changes in the business.
  • No one will tell them the truth.

Developers are afraid that:

  • They will be told to do more than they know how to do.
  • They will be told to do things that don’t make sense.
  • They are too stupid.
  • They are falling behind technically.
  • They’ll be given responsibility without authority.
  • They won’t be given clear definitions of what needs to be done.
  • They’ll have to sacrifice quality for deadlines.
  • They’ll have to solve hard problems without help.
  • They won’t have enough time to succeed.

(Thanks to Joe’s Wiki for the original transcription of the above.)

In addition to the human tactics (talking to people) of overcoming this fear, using tools that encourage transparency helps too. There’s a huge chicken-and-egg problem, of course, with those tools: if people are afraid, they have to get over their fear to start using the tools that help reduce their fear. My opinion is my usual “whatever <shrug> better to try than to sulk.”

Also, when check out this short post on transparency in the business end of things.

The iPod Scroll Wheel

The iPod’s scroll wheel has been through three iterations. The first one actually rotated; then there was the touch-sensitive one; and finally there’s the clickable one found on the iPod Mini and fourth-generation iPod. I’d always assumed that this bit of design genius sprang from Apple Computer’s labs. But in fact, I discovered that a company called Synaptics, which primarily makes touchpads for laptops, actually perfected this little piece of navigational heaven, in accordance with Apple’s stringent design requirements.

“The secret of iPod’s scroll wheel”

Sky Cap'in

Holy crap! the
Chronicle gave Sky Captain and the World of Tomorrow 4 stars
. That’s unexpected. From the previews, I thought that movie would be a celluloid shit-heap. And it’s from that Savlov dude: he never likes nuthin’.

Looks like it’s doin’ all right elsewhere too.

Maybe I’ll have to go see it. We were talking about it at lunch today, and it sounded like it was Hollywood-fuckable proof, since that dude made most of it in his bedroom, and they just threw in actors later.

Complexity, Value at the Edge, Re: Software Renovation

In a recent study of more than 20 large enterprises, Boston Consulting Group found that as time went on and these large companies acquired an expanding arsenal of IT, far from gaining economies of scale they were in fact left with “diseconomies of complexity.”

Traditionally architected IT systems tightly intertwine so many aspects of the business processes they automate that making even simple changes to some facet of the operation is enormously difficult. Similarly, it’s difficult to get several systems — each originally installed, potentially, by a different business unit pursuing its own tactical goals, with no coordinated planning — to share their data or cooperate in executing complex business transactions. Either a company springs for a costly integration project or its employees cope by opening different applications on the same crowded PC screens and flipping back and forth between them.

While I like the write-up of the problem, as a somewhat experienced coder and reader of trade-rags over the years, I’m suspicious of the claim that SOA is anything close to the Silver Bullet, e.g., with SOA, “[i]n other words, monolithic gives way to mix-and-match, as Lego-like building blocks of software are recombined in almost endless combinations.”

I mean, that’s the line people have been using since the beginning of software-time about every vendor/design fad that’s come along: structural coding and analysis, CASE, OO, Modeling, Java/.Net, BPO/BPM, Web Services, and now SOA.

It goes on to point out that several group in companies have been tempted by creating ad hoc web services to enable integration without company-wide architectural planning. Thus, down the road, the company will end up with a spaghetti web services architecture.

That’s certainly true, but I don’t think the answer is to go out buy a bunch of expensive SOA tools, or even start running around saying “we’re SOA, yay!” The answer is for the corp. Architects to come up with a data standard and certification tests for that standard. They give this standard to all those small, ad hoc web-services-using groups, and tell them their services must comply with the standards. Then, they setup their certification tests to run against every new web service. As long as your ad hoc, or over-engineered, or however it was developed web services app passes the tests, you’re good, and the company can try to dodge the spaghetti bullet.

That’s one of the annoying things about corporate wide efforts lead by a vendor push for something like SOA: simply buying, installing, and using some SOA system or apps isn’t going to do anything for you. The company still must decide the format the data will be in so that all these apps integrate with each other, and enforce the application’s use proper use of that format. While it’s easier to do the first, I’d wager most companies have down-right terrible time doing — or even realizing they need to do — the second.

That grip aside about SOA hoopla aside, there are good points in the article, e.g., towards the end:

[T]o make the most of the technology, companies will have to move away from centralized control toward “federated” decision-making. “This is particularly true because much of the business value of Web services and SOAs is coming from connections established across enterprises — for example, in supply-chain or distribution-channel management processes — where there is no single decision-maker.”

That fits in well with all the “value is increasingly at the edge” that’s resurfaced, e.g., on The Gillmor Gang last week. The focus in this line of thinking used to be on the at home end-user: back in the Netscape days, anyone could publish a web page, so all the sudden your neighbor was going to start a web empire in his bedroom and trump the New York Times. Recently, it’s moved more into the enterprise world: people aren’t becoming more productive because of corporate wide initiatives and apps, they’re using things like IM, weblogs, wikis, and other skunk-works (the old word for “edge computing” in the company ;>) things. The above on The Gillmor Gang has a good discussion on it.

Additionally, this article fits well into the software renovation line of thinking. Besides the agility that SOA would give you, the proponents of SOA tout it’s ability to integrate all your apps together. That of course, is huge. Again, I don’t think SOA on it’s own is the savior for this: a corporate wide data standard is. That way, even if an app isn’t SOA (I’m not sure if any app couldn’t somehow be crammed into SOA shoes), it can work with the rest of your corp. apps if it complies to the data standard.

(Via CenterBeam News Log.)

Re: "Scarcity used to be for engineers"

Along the lines of some quoted text in a previous post:

Management skills have never been highly valued or utilized in small companies. When you’re working with 10 other people, it’s just not that needed. Also, entrepreneurs tend to get excited by doing — coding, writing, designing, etc; Not by managing people who code, write and design. But, with today’s ability to work with people all across the world comes the the great responsibility of needing to manage them to get what you want. It’s going to change the required skills for successful entrepreneurs. Successful management ability early on, not just great drive and persistence, is going to become an absolute must.

From Joe Kraus

Which, really, just confirms what Arley said in reply to the original post:

There’s no scarcity of managers. There’s a scarcity of software engineers willing to work for the illegal wage of $4/hour. That’s the only scarcity I see now in American IT.

Wha-BAAM! Whenever I think I have the market cornered on bitter-cynasism, Our Man in Houston shows me who’s boss ;>