But generally, I agree with your article - the KISS principle still holds true

EA has its share of problems, but they seem to generally understand how to make a product that appeals to people and accomplish what it sets out to do.

I’m somewhat worried about Spore.

Such complexities almost certainly wouldn’t hold up to the “What problem are you trying to solve?” test if put to the authors of the complexities. They might argue that their complexities are necessary, but in that case I’d argue that they’re solving their problems on the wrong level, and that they ought to be the ones backing up a few steps from their problem and looking at it.

However, you’re right that given the scope of control of the average software designer, those things are out of control. Usually what I do (and what I’d imagine most designers would do, in such a situation), is to somehow “isolate” those complexities from the rest of the system, so that the pieces of the system itself remain simple, and the complex parts don’t “infect” the whole design.

-Max

thanks for your reply - i think we may speak about different issues. I’m completely on your side when it’s about introducing (or better not introducing) unnecessary complexity by technology. So i’m not talking about under- or over-engineering a technical solution.

My comment is rather about complexity that’s driven by forces you can’t control from the technological point of view (and even may be not under control of the company). Take the field of ‘compliances’ in the financial market (Basel II, MiFID, SOX, AML to name a few) for example.
Fullfilling those compliances will introduce ’some’ complexity that you have to face. And by reflecting those rules, some ‘pieces’ (refering to your fourth law) of your code will reflect those complexity.

Of course you don’t want to add additional technological complexity by choosing appropriate design decisions (considering the given forces), but the non-technological complexity is inherent.

Of course you could argue that complexity is bad and won’t pay of in the long term per se, but unfortunately you’ll sometimes have to accept it, because it’s not under your control (even with self made complexity by the company - as long as their business model is successful, they’ll go along with it. Even for short terms of 10 or 20 years. Business will drive the requirements and thus sometimes complexity, IT have to follow).

Greetings

Mario

Also, just because some complex products survive in the short term (like 10 years) doesn’t mean that they have actual staying power. I think complexity can be reduced from requirements as well as from the design.

-Max

but sometimes complexity is out of your control and not of technical nature.
If you for example face a complex business model, you may have to come up with a model that reflects that complexity even if you adopt sound design principles (e.g. loose coupling, …), methods (e.g. communicating code) or whole paradigms (OO, DDD, …).

Of course, complexity shouldn’t lie in the applied programming techniques or design decisions itself, but often comes from the underlying enterprise (i think we all have seen not only one company that describes a business model where their ‘pony’ have to fly to moon … and that’s their right since they will make money with that business model and pay their employees :o)).

as someone said correctly: technology shouldn’t be the problem, its the business that matters … and sometimes that business is complex per se …

Greetings

Mario

Changing requirements can be dealt with by keeping things simple. I can’t go into it in detail here, but that’s the basic idea.

Vague requirements should be dealt with by clarifying them. I write requirements documents all the time, and that is how I deal with it. You can go back to the customer and ask them what they mean.

Simplicity is not a popular sentiment because many developers don’t understand the basic principles behind it, or why you would do it. People also tend to reject technologies that they don’t already know about, particularly if they know one technology very well already.

-Max

Ah, yes, I agree with the complexity problem! I touched on it two earlier blogs, and it’s pretty much one of the primary focuses of my book.

And you’re completely right in the last paragraph, too. Reminds me of another blog I wrote.

-Max

-Max

-Max

Most of us do not have the luxury of Google’s in-house, bottom-up driven approach with beta periods lasting years but have real customers with vague requirements and feature fever. I wholeheartedly agree with you regarding KISS, but I also find it to be somewhat unrealistic in the typical top-down complex environment most of us are subjected to. I continue to try to push for the right blend of “simplexity” in my organization but the problem is that we all view that differently. For example, I find the new LINQ stuff and the RoR conventional style to be vastly superior to the monster JPA/EJB/JSF black-box stacks we’re using but that’s not exactly a popular sentiment.

Besides, think about what you are telling management: we’ve spent all your money making a piece of crap and now we’d like you to spend it again so we can make a different piece of crap that does the same thing. Good luck! A better request would be “please spend 2-3 times what you just spent so we can analyze our practices and determine how we can avoid making the mistakes that got us here in the first place.”

Max — great entry, I wholeheartedly agree. However, you haven’t touched on the core of this problem I believe. You see, while the customer frequently asks for things that are unnecessarily complicated, it is the architects and developers who more often produce the complexity that eventually brings down the ship. Technical folks tend to love complex things. It’s part of their nature. Even things which are born of simplicity eventually become — if left to their natural progression — too complicated. Layering, “future proofing”, complicated callback schemes, etc.

What’s nice is that simple solutions are often the answer that survives — much like a game of Life where stronger children survive while weaker ones die out. Take Google, for example, which greatly simplified search. It focused on the primary need — finding things — and did that well without all the bloat. Most of Google’s products fall into this pattern of simplifying things and attempting to stay simple, while other companies take the opposite approach, cramming as many features as they can into a product and then attempting to make it scriptable, embeddable, etc.

Business folks and developers alike could do with a big dose of YAGNI (You Aren’t Going to Need It). Focus on the simple need at hand, solve it in a simple way, and move on to the next real requirement. Refactor, repeat. This will often prevent the problems Casper alluded to, and if you iterate in small pieces (an agile philosophy), you’ll end up with what the customer needs rather than a nest of spaghetti code and spaghetti requirements.

monk.e.boy

-Max

-Max

-Max

May be true with your boss. but in reality this is the same reason why open source project are unable to fully leverage the market than the commercial vendors.

It is great to see open source experts forking and perfecting their solutions , but the hardline is that they are trying to match an already existing commercial solution or doing some generic application…..

“Water is useful only if it is accumulated , directed, purified and distributed across dedicated pipelines..”.

However, i agree that todays IT managers cant be just “film directors” they need to be more a “servant leader”.

Anyways… by agile .. what i mean is simple “do something.show..improve on. show…iteratively..quick”.. note i am using “improve”.. not “show”…also..”perfection is sometimes pronounced as a disease”.

Good..Max… take care

-Max