Skip to main content

Design is King

Our field is a young one.  Young in terms of the average age of engineers in the field doing work.  This has the unfortunate side effect of the same failures to repeat with each generation of developers.  I've been in the field to see a few generations go by and the same mistakes re-appear.

Every few years there is talk (hype really) of how a new language or tool is going to revolutionize software development.  The IDE's Languages, development methodologies, etc. are the "hot new thing" in the field.

But I've never found that true.  I can still code and produce the same code with the same quality as I did 20 years ago.  The basics are the same, edit, build, run, test.  Yup the tools and computers are much faster today so the cycle time is quicker but it's not 10-100x faster.  More like 2-3 times faster than decades ago.  So what makes one type of development or a project much better than another?

From my perspective it's the design.  Design trumps language, tools, dev-process every time.  It's not just a big factor, it's THE factor in development.  Without a good design any project is at risk.  Either in primary development or in support / maintaince mode.

When ROR (Ruby on Rails) was released it was herald as a great leap forward in productivity.  My thought's on ROR was that it's was just a solid Web MVC design that developers could use.  Any good Web MVC design would make developers vastly more productive, regardless of language.  hype aside, it's the design.  People jumped on the language as the saving grace.  It's not, it was the MVC web design that just happened to use Ruby.

The problem with young (< 40 years old) developers is that they all want to create their own designs and they think they are good at design.  They are not.  Not all of them anyway.  They would rather use a new shinny object to base their project on than to use a proven design as a foundation.   Very few succeed in the creation of new designs, but the hype never ends.

In the end, only the best designs survive, along with wiser engineers.  When things fail, it's the wise ones that help put things back together again.

Comments

Popular posts from this blog

My Current Desktop and Happy Vining.

It's been a big switch when I quit my old procession (Software Engineer) and ventured into the unknown.  So this is my current desktop.   First it's a REAL desktop and not a computer screen. Second, I've had to learn a whole new set of tools.  You would think a pencil is just a pencil and a paint brush is just a paint brush, but noooooo, they are tools into you mind and that's what needs re-tooling. The tactual nature of these tools and operation as much more rewarding (and frustrating too) than typing code in an IDE.   That had it's incentive but that well went dry and life changes,  so I changed. The pleasure of creating colors (no RGB involved) ad hoc wise is interesting.  Getting the technique to merge them on paper is very tough.  You do not know what you're going to get, so you just have to go with it. I'm glad that I can do a lot of other things instead of Software, but I hope that others in my past procession work on other pa...

3rd Try is a Charm

I've been trying to draw / paint these barns for a couple of years but never felt or got them right.  This time I think they turned out right. So What went wrong before and what's right now with this drawing?  This time, the light was right.  It's coming from the upper right and the shadows just looked right.  The other thing is the corn field on the left had to "be in season", otherwise it's just a plowed field.  I had taken other photos from different angles but they never felt right.  This angle has the road, power lines, corn field, etc. all leading to the right.  The shadows on the lower right helps fill in that corner (don't forget about the corners!).  The last part is trying to draw (ink paint maybe) the trees in the background.  Not so easy when they are kind of a blob is green shades. So yeah, it's composition that is king.  Many times I just don't see it until the drawing / painting is finished and when it's right it feels goo...

Thought Patterns

I know how I work.  How a think about, visualize a problem and go about mentally design a solution and implement it in code.  My thought pattern works pretty well for me on most occasions, but not always. There are times when I have a force myself to change my thought pattern because of the problem I'm solving requires a different mindset.  Anyway, this posting is about how I work most of the time.  Here is goes. I quickly break down a feature into operations that are required to exists and tackle that code first.  My thinking is that, if I can solve the primary issues first, then secondary features will fall into "known knowns" and I can address those at anytime (and sometimes at my leisure) and this allows me to meet my internal timeline. If I addressed features and operations that are not primary first, then I feel I risk my (and the projects) timeline without addressing issues that allow the feature to operate.  You may have seen this occur where...