Category: My Menu

Fred’s Laws (again)

Some time back (late September) I promised a series of posts on what I term “Fred’s Laws”, a set of rules you can follow if you are determined to have your software development project fail miserably.

Back in September, I promised I was going to post a law per day until I ran out of things to say. That lasted, well, zero days :-). For various reasons I felt it prudent to delay posting these for a couple of months.

The laws I am going to post are in no particular order in terms their impact. I am not sure how many of these laws there will be, and I am not even sure that they will not end up being self-contradictory.

(hey, I am doing this like a typical software project!)

I think the laws will fall into a few main categories:

  • Requirements
  • Project planning and tracking
  • Process, methodology, blah, blah, blah
  • Working with management
  • Working with marketing
  • Quality, testing, etc.
  • Technology and tools

Something to keep in mind here is that I am a big fan of process in software development. Not of big, heavy processes, but of some process. If you are going to go from A to B, you have to follow some process to get there. There is value in having some level of predictability and repeatability in that path. You may vary the path with the circumstances, but you should at least know what path you are improvising around.

Also, I do not believe that there are any rules which you can follow which will guarantee perfection in you software development efforts (at least not if you are building anything interesting). All of the rules, and process, and other magic spells can do is to improve your probability of success, and allow you to see when you are heading down the path of failure, allowing you to make some intelligent decisions along the way.

On the other hands, the are a few rules you can follow which can almost guarantee that your project will fail. Combine a few of them together, and you can make your failure truly spectacular. Stay tuned…

Advertisement

Leopard will open the Mac OS X floodgates (and embarass Microsoft)?

Leopard will open the Mac OS X floodgates (and embarass Microsoft) – nice thought, but not very realistic. The fact is, Apple will continue to eat away a Microsoft’s dominance, especially in certain segments of the market (primarily those who would not be running Windows anyway), but will not become the dominant desktop OS (and hence, will not destroy Microsoft) unless Apple stops being a radically proprietary, closed environment, and lets users buy the OS and run it on whatever hardware they want. Same battle Apple lost in the 80s – seems they never learn.This assumes, of course, that Apple wants to be an OS vendor – maybe they are not stupid, they just do not want to compete in that market.

What language is that?

We have all become familiar with various forms of slang, lingo, emoticons, abbreviations, and acronyms used in the IM and Texting world.

Well, today I had an experience which indicates I may be a little too used to it. I was browsing through various blogs (not ones to which I subscribe, just random ones), and came across a blog I was having trouble understanding. The author seemed to be using way too much slang, etc. After about 30 seconds of trying to interpret this post – it suddenly occured to me: this post was not using internet slang, it was in another language altogether!

New laptop & Another try at Ubuntu

Well, as I dicussed in a previous post, I have been in the market for a new laptop. I have finally bought one. I decided to go for a Dell XPS rather than Apple (mostly due to cost). Such is life – maybe I will try a Mac next year. It is my intent on my new laptop to either dual boot Vista and Ubuntu, or (if I have a good enough experience with Ubuntu), just run Ubuntu and do all of my Windows stuff in hosted virtual machines.

So, last night I take my brand new laptop, and my newly burned Ubuntu CD, and set out. Ubuntu boots up from the CD just fine, but the screen resolution sucks because Ubuntu is philosophically opposed to loading the drivers for my video card. No big deal, I can live with 800×600 until I get a proper install done. So, I click on the install icon, and away I go. Or, actually, I don’t. It seems the Installer UI is not expecting 800×600 resolution, and the buttons to let me proceed through the installation are lost off the bottom of the screen. I also do not seem to be allow to resize this window. It being midnight and all, I gave up. I am sure there is some way around this, but I did not feel like screwing with it.

I will probably have another shot at trying to set up Ubuntu or some other Linux distro this weekend. Maybe I will have better luck and not just give up on Linux (sorry folks – this is stuff that should just work!)

PS – Vista is working fine on my new laptop. Transfered my files and settings from my old machine using “Windows Easy Transfer” – not a problem.

Fred’s Laws – How not to write software

This begins a series of posts on Fred’s Laws – basically a set of anti-rules on how not to develop software.

Over the past twenty-odd years, I have seen a lot of software projects crash and burn. Many have been doomed from the start, while many others died slow, painful deaths after hopeful beginnings. Some have finished, and the systems are in production, without ever having realized that the project was a failure. Others should have failed, but managed to struggle through due to the heroic efforts of one or more dedicated (and usually really smart) people.

I have also seen more than a few “failed” projects that were technical successes. We built really cool software. We were on time, on budget, and had good quality. They failed in some other aspect – usually they were business failures for one reason or another.

The environments in which these projects have died have been varied as well. Some tried to make it with no process at all. Some had lots and lots and lots (and lots and lots) of process. I have not seen a great deal of correlation between process and success (well, except that the process I pick for my projects is always successful 😉 ).

When I look back on these catastrophic projects, usually I can see where things went wrong. In fact, most of the time I could see where they were going wrong while it was happening, like watching a car crash in slow motion, but was frequently powerless to avoid the impact. More often than not (in fact, I would be willing to say always), the root cause was something completely avoidable (from a technical or project perspective). Never was it because we chose Windows over Linux (or vice versa), nor because of the programming language we chose, nor because what we set out to do was technically impossible.

As I have written Fred’s Laws (well, written them in my head, none of them are actually written yet!) it occurs to me that they all seem to be straight from the department of the bloody obvious. No rocket science here. If they are this obvious, why even write them down. Well, the reason is that, despite how really obvious all of this is, I watch projects not do them all the time. Most of the time, in fact.

So, stay tuned. I am going to try to post one law per day (or so) until I run out of ideas.

BTW, as a little footnote, I have been involved in a few successful projects along the way. It just always seems to be the ones that failed (and failed spectacularly) that stick out in my memory.

PC World – ISO Rejects Microsoft’s OOXML as Standard

ISO Rejects Microsoft’s OOXML as Standard

The title is somewhat misleading – OOXML was not rejected as a standard, but the attempt to fast track its approval failed. This is a good thing. While a setback for Microsoft, it now will allow some of the comments raised against the specification to be addressed before a new vote occurs.

Unfortunately, it means we get to listen to much more of the ODF vs OOXML, “Microsoft is evil” babel.

Such is life.

Service Oriented Architecture is your Ticket to Hell?

With reference to Service Oriented Architecture is your Ticket to Hell, it always amuses me how people insist on calling any idea which does not agree with their own, “bullshit” – always thinking in terms of absolutes, and believing “my ideas are great, yours are BS”. Remember, an idea is a dangerous thing when it is the only one you’ve got. The statement that Service Oriented Architecture (SOA) increases agility can be interpreted in two ways: as increasing the agility of your architecture, or as increasing your ability to adhere to the dogma of “agile development” (which has been bastardized as much as all dogma ultimately is).

(of course, I tend to think of SOA in the dogmatic view of Erl as somewhat bastardized as well, and I do not recognize his authority on the subject as absolute. I was modeling systems as collections of autonomous interacting objects/services years before the term was hijacked)

I will start by looking at the closing statement of the post, since I actually agree with it:

What I am saying is that, if SOA is scaled up without precaution, it can create systems so precarious that anyone asked to maintain them will feel like s/he’s won a ticket to programmer hell.

While I agree with this statement, I do not agree with specifically targeting SOA. This statement applies equally well to any architectural model, including any emergent architecture coming out of an agile development project.

Lets now look at the two specific concerns expressed with SOA.

It is not entirely clear to me that SOA requires excessive amounts of “up front” architecture. The only locked in architectural decision is the one to model your system as a system of interacting services. Even the choice of what kind of a service bus to use should not imply lock-in, since if you implement things properly, it is not particularly onerous to move services from one context to another. And the decision to model your system as a collection of loosely coupled services does increase the agility of your project, in some respects. Need an additional execution component? It is fairly easy to implement it without disrupting the rest of the system. Need to take one out, or change its implementation? Same thing.

Looking at the second concern, I would agree that is possible to create “strange loops” and other architectural oddities through unconstrained application of service oriented architectures. The same was said for a long time about inheritance dependencies in object oriented systems.  It remains important for the architect of the system itself to understand the implications of any services being used. This is an inherent complexity of large, complex, distributed systems.

(as an aside, this is a fundamental problem I have with agile methodologies – the idea that up front architecture is sacrilege – and I have seen little to no evidence the agile methodologies scale to large, complex projects).

As for the comparison between object oriented approaches and SOA, I do not see the two approaches as being mutually exclusive. What are services but large scale objects which respond to messages and provide a service/behaviour? Much of the same modeling concepts which apply to OOAD also apply at the larger scale (of course some do not – such as granularity of operations).

Ultimately, I find SOA to be a useful approach to modeling large, complex distributed systems (and yes, I have built a few). Is it perfect? Probably not. Are the “gothcha’s” in there if you apply it blindly, and without due thought? Absolutely – the same as any other approach I have seen. Is it the correct approach for every system and every project? Absolutely not. It is one approach. It pays to know more than one, and to use the correct one in the correct situation.