Good Design

Someone asked me on a phone interview how I recognize a good software design. I think I managed to mumble some kind of response after blabbering a bunch of “uuh” and “aah”. I didn’t get the job, obviously, but since then I’ve never put the question to rest. It kept hunting me, distracting me like an annoying fruit fly that just won’t go away.

So I put a lot of thought into this and managed to get only as far as realizing that the following are signs that you have a good design:

• The code is readable. By reading it, you can extract knowledge from it with a minimum of effort.
• The code is reusable.
• The code is easy to change.
• The code is succinct and to the point.

Maybe I need to call the guy up again and tell him all of this. “Hey, it took me a month, but here’s what I think is essential in a good design!” Sure, it all looks like common sense. But that also means it is pretty rare. I find it incredibly hard to live up to those four intuitive guidelines. Sometimes I even forget that they exist!

Finally, I got my feelings validated a day or two ago when I read a blog post that mentioned the four qualities of BAD design (I apologize, but I can’t find that post anymore!):

• rigidity
• fragility
• immobility
• viscosity

Rigidity means your code is hard to change. Fragility means a change will break everything. Immobility means your code isn’t reusable. Finally, viscosity means that your stuff is hard to read and understand.

Wow, that’s exactly what I was thinking about! Now let’s get to work and apply all of this on a daily basis, shall we?

The answer to anything and everything…

… hasn’t been found yet in the case of software development.

We used to say that a good singer could sing the phone book without boring his or her audience. Nowadays, I feel like a good test for  singers would be to make them sing all the Agile acronyms without putting our managers to sleep. Or when your tired at night, instead of counting sheep, recite the acrony… Zzzzzzzz…

In the past couple of years, we grew so fed up with the classic waterfall model of software development that we started shooting in every direction at once in the search for the right way to develop software.

We have Agile development, with short and fixed iterations. Then Lean software development came about a said to hell with fixed iterations! We do it like Toyota is doing it (so much so that I actually wonder why they didn’t call it Toyota Software Development, or TSD in short.) This is where a lot of our Agile terms come from, by the way. If you ever wondered what was up with all the Japanese terms in our field today, they come from Toyota: Kaizen, Andon, Kaikaku and Kanban are the ones I’ve heard the most, but there are about 10 others.

Sprinkle all of this with a bit of DRY, POCO, SOLID, DSL, BDD, TDD, DDD, IoC, MVC and PVC and you get a giant pool party where only the smartest ones that have had time to research all this are invited. It is our own Playboy mansion party!

It’s like being 15 all over again

It seems like we are entering our teenage years as a community. We are going through our identity crisis, trying to figure out who we are. Is writing software like building a house, or is it like manufacturing? Maybe it is like growing a garden? It’s probably none of those things. We don’t know for sure and these days, we are sticking with the manufacturing metaphor. Maybe in a couple of months we’ll think coding is like being in the police: you take your problem and circle it, make sure you have your snipers into place and don’t let any bug escape!

Eventually, however, we’ll start settling down in the same way other, more ancient fields have done. Engineering has it’s own set of rules and guidelines, and so do the people in manufacturing and construction, lawyers, cooks, doctors and party planners. They’ve been through it before. In the meantime, being teenagers, we get excited by the new stuff: “this new watchamacallit is soooooo gonna replace Kanban boards!” But it the end, we need to show restraint.

What has been very hard to me recently was how to learn everything and how to use the new methodologies. Behavior Driven Development and Test Driven Development, for example, are two ways of driving your development. There can be only one driver, however, so which one is it? It seems like BDD has superseded TDD and is the way to go. Thank God I skipped TDD!

I also started learning Domain Driven Design to be a better designer. However, the methodology calls for a lot of coding *while* you design your model. Ooookay, so do I have to code using BDD? I guess I could! And where does Activity Modeling fit into all this? Hmmm, I could use it to help me figure out my model. But where do DDD and Activity Modeling meet? At what point do I switch from designing the user experience to designing the domain model? I know they overlap a bit, but not completely. Do I use DDD to create my model layer and the create the app and UI layer using activity modeling and user stories? And can you use a Kanban board if you do DDD?

Etcetera…

This stuff is hard and people can’t do and test everything out. Some methodologies are known to be incompatible and some might repel each other, except that we don’t know it yet! Some very smart people are doing the hard work of figuring it all out and mostly end up saying that “you don’t have to follow every methodologies to the letter.” Great, now we can mix and match to circumvent things that won’t work together. What’s more, each team is different. What works somewhere won’t work everywhere. We need to adapt.

God damn it, I feel like a freaking headless chicken right now! Nobody has a perfect answer, everyone is still searching and every branch has its own dedicated evangelist saying that their way is THE way. I almost want to give up. The waterfall model seems so attractive compared the junk yard of methodologies in front of me…

Let’s make this work

Okay, let’s see. What have we got here…

Here’s what I know:

• Coding takes time: a loooong time.
• Coding always takes more time that you think
• Coders are a constraint in the system. Software cannot be shipped faster than coders can code.
• Modifying code is hard
• Programmers and users never seem to understand each other

Being a constraint in the system, coding must at all costs be protected so that it never stops. While this is all good in theory, it won’t be so in practice because we have to talk to our users, fix build servers, etc. This is what I like about Lean development: the idea that one must look for waste and get rid of it. In my mind, waste is anything that slows down development, like interruptions, waiting for customer response, waiting for DBAs, business analysts or managers. All of this waiting should be minimized, and any technique that helps you do that is good.

Oh, and why not throw in some good design practices in the mix? Your code should be easy to understand, easy to modify, easy to test and easy to reuse. Phew! Now for the rest of us mortals, try to make it as easy as possible, okay? Taking the time to understand code or being stuck when adding new features to unmanageable code: this is waste.

Another form of waste is the fact that users never seem to speak our language. This is why I love DDD. It helps develop a domain model and language in unison with the users. If done right, it increases the chance that the software will actually do what the users want! Novel, I know…

Hence, every methodology that I will ever follow will do the following:

• Protect the coder by minimizing waste, and
• Help users and coders understand each other

That’s it. The rest are just tools to help me achieve the above points.

It took since the industrial revolution to get to the way Toyota manufactures cars today. Software development is barely 40 years old. Hang in tight, it’s going to be a bumpy road.

Caffeine

Coffee tip#1:

Did you know that there is more caffeine in lighter roasts than in dark roasts? The roasting process burns away the caffeine in the coffee bean. While it might seem that the stronger taste indicates a stronger coffee, what you are tasting is just burnt oil.

Espresso beans, which are just regular beans that have been roasted darker to remove unwanted acidity in the taste profile, do not contain more caffeine than regular beans.

A 7 oz cup of drip coffee contains about 115mg of caffeine whereas a shot of espresso will contain 100mg. However, some espresso blends have a small amount of robusta beans. These beans have a higher caffeine content and might increase the dosage a bit. By the way, never get a cup of 100% robusta. That varietal is awfully bitter, almost undrinkable.

In the end, if you’re going to stay up all night programming, you’ll be better off drinking a light roasted cup of coffee then a darker one, or even espresso! What’s more, light roasts taste so much better. I purchased a small home roaster a year ago and have been roasting my own beans. In the morning, my cup of coffee leaves me licking my sticky lips, craving more. Yes, my lips get a bit sticky because of the very flavorful oils in the coffee beans that you don’t get from store bought beans. The oils disappears about a week or two after the roasting process.

Resolution

I'm 6 days late but I found one goal for the new year, which I'll hopefully attain before the summer.

I want to run a sub-20 minute 5k.

I already broke the 30 minute barrier, which was enough to create a loud BANG noise. Er.. no, wait. That's the sound barrier. Never mind.

Why running a sub-20 5k? Because We have four 5k races at work, once a quarter, where the winner gets $150. That's $600 per year!

And I want it. The problem is, there's this guy in my age bracket who runs the 5k in about 21 minutes, hence the sub-20 goal.

Training

I'm planning a toned-down, cardio centered crossfit workout during lunch, with one or two days of strength training every week. I will also run in the morning, 3 or 4 times a week doing mainly sprints like 4x400m or 8x800m and a longer run, maybe on Saturdays.

I'll also go back to my no bread, no sugar diet for a while, which is going to slim me down quite a bit. I'm hoping I can lose 10 pounds, which I won't have to haul when I run.

Goals

It's good to have a goal again! After attaining my goal of reaching my BMI last year, I was kind of in limbo. I didn't know what to train for and I wasn't very motivated to go to the gym . On top of that, I started eating bread and sugar during the holidays and had to go back a notch on my belt. Not good.

But now, with this new goal, I should be all set! Waking up early is gonna be a bitch though...

Format change = process change

I have just read that Dr. Dobb's Journal is going Web-only. My question now is will they try to fit a square peg in a round hole?

Traditional print magazines gather articles and publish them on a strict schedule. This is imposed on them by the publishing industry, where it is more cost effective to print one million copies every month then to make half a million every other week.

By going online, however, a magazine becomes free of that constraint and can release content every day or so. I hope that Dr. Dobb's Journal change their process this way instead of doing it the good old way just because "it's what we've always done!"

I have a subscription to the Crossfit Journal, a newsletter turned online magazine about fitness. They moved away from a monthly PDF to continuous content creation, which is a fabulous way to make your customers come back for more every day or two. Also, reactions to articles and discussions happen on a much shorter span where authors can respond or react almost immediately.

Changing your medium is a great opportunity to change your model for the best!

Alone in the back country might be a good thing

The whole reason for this blog is to keep me connected, somehow, to the technological world where most uber-geeks live. I copied myself on the Internet through this blog, Twitter and Facebook to create the illusion that I live in this beautiful giant metropolis where bits fly down the highways and jump down from the high rises that are the layered applications of the World Wide Web.

My hope was to one day get back and live in a real city like Austin or San Fransisco, strong from all my digital connections. This all changed, however. I might not want to live in a big city anymore. Not since I've read this article on Boston.com, anyway.

Cities are bad for my brain? That is definitely a thinker. All the things that I grew up to love about cities prevent my brain from operating at its full potential by saturating it with useless sensory experiences. In contrast, nature tends to heighten and relax the mind, studies show.

This seriously makes me rethink my strategy. While I miss the sophistication of bigger urban areas, with their 20 varieties of blue cheese and exotic food and restaurants, I also crave the quietness of nature and the sight of water.

As software developers, we are incredibly fortunate to be able to telecommute and work at a certain distance from our customers. Technology is helping us by allowing us to stay connected without being physically together. IM software, emails, scanners, the Web, Google Docs and now iWorks from Apple now allow you to share data online. More and more, people have the tools they need to connect and meet on the Internet.

We already see user group meetings online where one can attend from anywhere and contribute to the discussion. Apple enables you to present a keynote presentation (similar to power point) through an IM session. I'm positive there is already a tech book club online. Hell, IRC has been very useful for years already! What about Linux? It's been developed by people who lived all around the world.

Plus, I can always order my blue cheese from Amazon.com. Hmm, maybe it is time to move further into the wild! All I need is a T1 line and I'm all set!