I actually come more from the engineering end of things (educationally, at least) than the Comp Sci route. I hold a Masters of Engineering, and my degree involved more electronics and mathematics than software.

The parallels between ‘proper’ engineering, and software engineering are compelling. I guess that the difference is the ‘environment’ the work takes place in - traditional engineering disciplines have to deal with the real world, and minor hinderances like physics. Software engineering takes place in an environment which is - somewhat - divorced from that.

(Sure, you’ve got problems like bandwidth, speed of light, heat build up, electrical supply. But those are dealt with by other engineers).

That sad thing, I think, is that although software development should be like traditional engineering, usually it isn’t. Failure is acceptable, even expected - “To err is human, but to really f%^k up takes a computer”. Time and again I see projects with inadequate specification, unclear goals, unrealistic budget, etc. and I think ‘This isn’t how you’d build an aeroplane’. Well, okay, sometimes it’s a car, a bridge, or a rocket.

I guess it’s a question of consequences. If a server falls over, you restart it. If a plane falls from the sky, it’s a big deal. So planes are expensive, and don’t crash very often, and servers aren’t, and do.

I read Richard Feynman’s “Personal observations on the reliability of the shuttle” and the thing that really struck me was how he actually praised the quality of the Shuttle’s software. And it seems to me that they achieved this by treating the software exactly like an engineering discipline, and accepting that this adds time, effort and cost. Sadly, most companies will not accept this. Sure, they might say they want 99.99% reliability, but you try getting them to pay for it. The difference is, NASA can’t afford failure.

Comments from my old blog:

Great post - I agree totally.

The costs associated with commercial development projects show why open source software has found a very solid position in the market - for the “mission critical” tasks such as web servers and database servers.

It’s the difference between something being built “good enough for the money they paid”, and “as good as it can be”.

By Jonathan at 09:22:19 Thursday 12th July 2007

Okay, so I’m a simple man really…

I’d been asked to demo a custom workflow to a customer. They’d some fairly clear requirements, and we just wanted to knock up a prototype. It was all about filling in ‘fields’ in a word document. “Great”, I thought, “we can allow them to do this entirely within Word”. And, looking at the marketing bumpf, the demos and the docs, yeah, we could. The workflow task could be displayed in MOSS, and the document properties pane would expose any other fields they needed.

Except… …I couldn’t get the ‘Edit this Task’ button to appear in Word. I know it should be able to - but it wasn’t. I tried everything; nope, nothing. In the end, I ran out of time - but one of my colleagues, of a slightly curious nature, kept plugging away at it.

It turns out, it was the wrong version of office. It used to be that versions of things were simple - there only was one for each ‘iteration’ of the software. Then we started getting ‘Home’ and ‘Professional’ - which was okay, and seemed sensible, to be honest. I liked that - it was simple, just like me.

Nowadays, I can’t f%$king understand the versions of anything Microsoft. Visual Studio - Express, Standard, Professional, Tools for Office, Web Developer, Team System - Architects, Team System - Software Developers, Team System - Testers, and Team System - Database Professionals, and Team Suite. Does that sound f$%king confusing? Do I have time to learn about all of these? And Vista! It has Starter, Home Basic, Home Premium, Business, Enterprise, Ultimate.

Similarly, it turns out Office now has - Home, Student, Basic, Standard, Small Business, Professional, Professional Plus, Enterprise, Ultimate, Magnificent and Pan-Galactic. Okay, I made the last two up, but WTF! I don’t have time to learn all the features of all these versions - and trying to find out about their features is a wee bit opaque. I shouldn’t have to work this hard to know what Office can do. I’m helping generate their sales.

So, my colleagues testing suggests that the Office Professional edition does not support the SharePoint Workflow integration. We’re not sure though. But he did find that it worked in Enterprise edition. A long road, just to find that out.

Comments from my old blog:

We’ve had this discussion w/ Microsoft as well. FWIW: Office Pro Plus works w/ WF integration as well. Additional word of Caution: To use the InfoPath control for workflows, you will either need Forms Services running to run ASPX forms, or you will InfoPath on each client to run the Infopath control. It is very hard as a ISV to tell our users what “versions” of Office they must have installed to use our features. Marketing should go back to the KISS principle, so maybe people would want to upgrade! It would also be nice if the MS documentation stated things like “This feature is only available when these product sku is installed”.

By TomC at 18:50:13 Friday 15th June 2007

I don’t think Jeff is talking about Brevity - and I think he even says that - but about Clarity. Clarity is simple, obvious, and to the heart of the matter. Real clarity is brief, but easy to read. That includes comments, too.

It could be made shorter in ‘text speak’, but how clear are those messages? There is a reason we don’t use 1 letter variable names!

It’s not tiny fragments of obscure code that does massive amounts (yes, I’m thinking of Perl in that, amongst others). And it sure as hell isn’t about lines of code - many languages (with notable exceptions) let you put an entire program on one line. Ever tried reading one? I did - you can’t.

It’s just about being simple, clear, and to the point. It’s kind of like Buddhist enlightnment - someday, with enough practice, I’d might just achieve that.

Unfortunately, I do think that we’re constrained - people often expect very complex things and lots of features from their software, and when people are demanding complex programs, you get complex code. Look at the complexity cost of, say, just having a simple UI for a Windows app, as opposed to a console app.

Some of the comments are very good, too. ‘Mickey’ is right - often, we’re trapped by bloated design. KISS is my watchword (and occasionally gets me a slap too).

Fred Ross is right, too, in his comment about code maintenance - but he does miss the point that often we’re under pressure from the boss to ‘just get it done’, and the idea of ‘get it done, but in a way that will save us time later’, well, usually, that dog won’t hunt.

Someday, we’ll get past the idea of using lines of code as a metric for how ‘good’ code is. I guess the problem is that clarity is more ethereal.

Comments from my old blog:

I agree with most of your points - but diverge in perhaps the same places you might too.

Examples… a typical .NET web application - which has C#, HTML, DHTML, Javascript, horrific call backs for AJAX, SQL, Stored procedures, triggers… the list goes on. There doesn’t seem to be any sensible way of making it “simple”.

The other problem (at least in my recent experience) is RAD or AGILE development… which often leads to spaghetti code unless the client is willing to pay a huge code tax for re-writing swathes of the project.

By Jonathan at 09:20:28 Tuesday 5th June 2007