There’s a quote often attributed to Albert Einstein that I quite like (and I’m sure most do):

Everything should be made as simple as possible, but no simpler.

There is some investigation as to if he said it or not, but the point remains regardless of who said it.

It’s easy to take this idea and apply it to things that we do in everyday life that we don’t want to do, right?

• I don’t want to clean my room, so I’ll tidy it up just enough.
• I’ll do just enough work to satisfy the clients, and that’s enough.
• I’ll fulfill [whatever responsibility] the to [lowest degree possible] and because Einstein [allegedly] said it, who am I to argue.

Even though I don’t agree with it (and the discussion for that is outside the scope of this post), I do consider this idea within the context of web development.

And to be clear, I’m not talking about web design. I’m not a designer. I don’t want to speak on behalf of something of which I’m not a part. But regarding providing solutions for people using software or, rather, web development, I’m far more inclined and positioned to talk about this.

Strictly speaking, I find myself often wondering if we’ve made web development more complicated (and why we’ve done so) and if using the simplest thing that’s needed is all that’s really needed when building solutions for others.

Continue reading

One of the ideas that intrigue me is the “ship it or die” mentality. Regarding what it’s called, there are variations thereof, but the idea behind the phrase is simple:

If you have an idea, get it from concept to product as quickly as possible.

Sure, the idea of getting to concept to a product may also be called “concept to cash” but there’s never a guarantee that you’re going to generate cash, right? There is a guarantee that you can get it into a tangible product, though.

And in software development circles, there’s always a lot that a person can argue for or against the idea. Off the top of my head, the two pros and cons that come immediately to mind are:

1. Pro. Getting something done quickly that works and that [potentially] generates revenue.
2. Con. Weak architecture, maintenance, scalability, testability, and so on.

In short, there may be a tradeoff between how fast you can get ship something for a market and the architecture behind the project. Sometimes there is, sometimes there isn’t. Generally speaking, though, I think it’s safe to assume the former.

Furthermore, some may see the former as the easy way out, some may see the latter as an exercise in YAGNI or, even more simply, that the problem can be addressed whenever it comes up.

But what does this have to do with anything at the moment?

Continue reading