cwash into software » Meta/Blog

What I’d Tell Myself About Design If I Were Just Beginning

Chris Wash — Thu, 30 Jul 2009 02:25:26 +0000

From all the time I’ve spent learning design, there are a handful of things I’d hope to remember or re-read if I were to ever get amnesia and have to start all over again. For new comers and experts alike, I’d like to share a few ideas about design worth thinking about through musings and links to other material that has helped form my opinions (some more relevant than others).

The competent programmer is fully aware of the strictly limited size of his (or her) own skull; therefore he (or she) approaches the programming task in full humility, and among other things he (or she) avoids clever tricks like the plague.
–E.W. Dijkstra

Designers are something of an enigma to most people; however, the fruits of their labor are largely understood, well used and appreciated. Design is often considered to be a purely aesthetic matter: a matter of taste, of style, of opinion; we know a good design when it when we see it. But many times we can’t quite put our thumb on why it’s good design, or what makes it well-thought out, or pleasing. Maybe some of us can articulate what it is we like about design, but few connect the dots enough to notice recurring qualities in our favorite designs or think about underlying truths beneath those qualities. Even fewer still have the experience to know when to apply these qualities, within the proper context to produce a good design.

Programmers are equally if not more engimatic to general society. Perhaps on the surface for many different reasons. But, coincidentally developers are designing all the time; could this play a part, perhaps? Is this why we refer to the most experienced of our profession as “architects?” Aren’t we, by way of programming systems and wiring them together, inherently striving for greatness as designers?

Especially when you’re inexperienced, you’re very much focused on learning what it is about a design that you find compelling, agreeable, or pleasing. We value a good design so much that we spend a lot of time studying, talking about and debating what makes a good design. As the narrator (Jack?) in Fight Club admits he had become “a slave to the IKEA nesting instinct,” so too, I find myself in willing servitude of the design pattern instinct at times. More often nowadays I stop and catch myself, and I’d like to think I’m not the only one with this premonition. Too quick are we to whip out our design patterns books (especially right after we’ve finished them) and, as the first order of business, go to town solving problems we don’t have.

Few products today need to ship in shrink wrapped boxes as they once traditionally had to. The connectedness of the Internet, coupled with all of the modern advances in hardware have fundamentally changed the way we look at developing software. “Fast, cheap, good – pick any two” still applies, but fast is faster, cheap is a lot cheaper, and good encompasses much more today than ever before. Software development still lags behind.

The unwise developer makes all design decisions up front, for fear of getting the solution wrong. The enlightened developer creates the closest thing to a working solution now, for fear of getting the solution wrong. The former produces a solution that fits his view of the problem. The later continually adapts his solution to encompass others’ view of the problem. Which is more valuable? The unwise developer wants to be done, and will sacrifice alienating some users. The enlightened developer wants to be correct, and will compromise stability of the design. Why do this? Because inactivity leads to software rot, and we have techniques for dealing with changing designs. What good are our big up-front design skills when the requirements change?

Like Darwin encouraged us to do with our views of biology, we’ve ditched an up-front design model for an evolutionary one. There is increasingly a focus on software as an evolutionary process everywhere, and it’s phrased in many ways: continuous production (Cal Henderson’s explanation the best); the perpetual beta; “no such thing as done“, agility – openness and responsiveness to change. The risk of bloated software has lead us down a path to focus on and seek to create small, modular applications that create “business” value immediately, can be chained together but never grow overly complex. Our design decisions still exist, but they are on a much smaller scale, and with much more concrete drivers and concerns factored in. And we understand that we’re fundamentally in error when we make them out-of-context.

Others have thoroughly dealt with this topic in much greater detail than I can or care to. Neal Ford has written about what Evolutionary Architecture and Emergent Design look like. Martin Fowler has asked, “Is Design Dead?” and answered his own question. I would encourage you to read their thoughts on the matter, as my own conclusions are largely in line with theirs.

That being said, there are some tools that you should look to add to your collection as you go. Any craftsman must learn to master his or her tools. Just having the tool in your toolbox does not necessarily make you a good designer; because they must be used properly, in the proper context. Like Clint Eastwood’s character explains of his toolkit in Gran Turino: each tool has a job, its own context and realm of applicability. Also, resist the urge to apply them every chance you get. Much of good design is about restraint. Try to see them applied correctly, or incorrectly, and talk with others about it. Keep a conversation going; don’t allow your codebase to become stagnant. Continually question, strike the right balance and good designs will emerge and bad designs will improve. Your methodology may have you delivering in sprints, but good design is a marathon.

Here are the basic tools. There is a lot of material out there on these – easy to Google or find on Wikipedia. I am not going to offer any links or speculation, because I think these things should continually be discussed. You should be constantly evolving your own opinions and knowledge of them. They must be used, discussed and understood in order to be mastered.

Overarching Computing Principles – Reduce Complexity

KISS – Keep it Simple, Stupid.
DRY – Don’t Repeat Yourself.
YAGNI – You Ain’t Gonna Need It.
SOC – Separation of Concerns.

Basic OO Principles

Inheritence
Coupling/Cohesion (dependency)
Encapsulation
Modularity
Abstraction
Polymorphism

SOLID (Advanced) OO Principles

Single Responsibility Principle
Open/Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

Emergent Design Techniques

Test Driven Development
Continuous Integration
Refactoring
Project Automation
Continuous Production

To borrow a great closing quote from Brian Liles,

Do not seek to follow in the footsteps of the wise. Seek what they sought.
–Matsuo Basho

RubyRX NC

Chris Wash — Wed, 25 Feb 2009 10:23:34 +0000

The first Ruby I looked at was actually back in 2002, well before Rails, during college as part of a group project in a programming languages course. At the time, most of the information my team could find on it was in Japanese. I looked at Rails initially in 2005 and found some things I thought were lacking in the framework. I never pursued it much more than that because I didn’t feel like paying the early adopter tax. It had some growing up to do. But seeing as how I recently have been working with Prototype a lot, which aims to almost turn Javascript into Ruby, (a few plugins will get you even closer…) I’ve found a renewed interest in Ruby. I figured I’d take a closer look at what is going on in Ruby-land and to that end, I drove down to RubyRX in Durham, NC last week.

Career 2.0

Jared Richardson recently published a new book based on some ideas he’s been floating around in talks for a while. Jared stopped in at the Richmond JUG recently to give a talk and we were all really intrigued and entertained with his presentation. I was fortunate to pick up a copy of Career 2.0 while I was at RubyRX and it’s a great handbook for investing in your knowledge portfolio through sharing knowledge. There are a lot of useful tips on how to improve your writing, speaking and networking skills. Take a look at the book’s blog for more info.

Dr. Nil

I was interested in seeing Nathaniel Talbot’s talks. I had already seen his talk The Fear of Programming in video, which he has refined a bit and created an alter-ego “Dr. Nil” (Phil?) by asking developers to talk about their feelings/emotions and how that influences how you think and act. It was a very interesting talk. I also saw his talk Five Skills Every Freelancer Should Have and he’s floated the idea of spinning that off into a book. Keep an eye out for it!

HAML and SASS

These technologies were mentioned in a few different talks I attended and I found them interesting because what I’ve never liked about Rails is that its view templates had code snippets in them. This leads to tag soup and has been discouraged in JSP and other areas for a while now. I’ll blog more on this in another post. But HAML and SASS take an interesting approach. I have my doubts about whether or not it will gain the traction needed to make “pretty” templates a bigger issue. From what I hear, (and feel free to correct me if I am wrong) it seems some of the more prominent voices out there aren’t sold on it yet and have strong feelings about the whole idea.

Build Up Vs. Build Down

I write here often about what I’ve been doing with Seam and Java EE. Seam’s success has come from the philosophy that a developer’s job will be easier if there is a simple interface to a deeply integrated set of powerful frameworks. Grails has a similar philosophy. A common thread in talks I attended at RubyRX was the idea of building down instead. Seeing all of the neat tricks you can do with metaprogramming, this makes a lot of sense for Ruby and many frameworks in the Ruby world take advantage of this idea. There are some very interesting implications with these two paradigms and how they affect code reuse. But that’s another blog post…

It’s All Been Done Before…

Rick DeNatale gave a very interesting talk on the history of dynamic-typed languages and their parallel evolution along with static-typed languages. I always find talks about how languages have evolved to be fascinating, especially if you consider there are a number of problems that we just keep solving over and over again every 20 years. There is wisdom gained in knowing how we got to the present, and I’d like to think these kinds of discussions leave you with insights about where we’ll go from here.

In response to Stackoverflow #38/”Quality Doesn’t Matter That Much” — Jeff and Joel

Chris Wash — Sun, 01 Feb 2009 01:16:05 +0000

Update: Robert Martin is scheduled to appear on the Feb 10 episode of the SO Podcast. Should be interesting to see where things go. Also, Jay Fields has weighed in on the topic.

Update #2: Listened to the new SO podcast and am working on a short followup post. I just met another local boy and kindred spirit in Justin Etheredge who has also had a few things to say about this whole debacle.

I wanted to add my two cents to this philosophical, in my view very important, but not very pragmatic debate. For the uninitiated, the argument begins with the Stackoverflow Podcast Episode #38 which is a discussion between Joel Spolsky and Jeff Atwood. They discussed, among many other topics, some of “UncleBob” Martin’s recent material found in his book Clean Code, (actually, Spolsky cited Martin’s appearance on Hanselminutes as the spark to his comments), which Martin responded to with a number of tweets and a blog post.

Jared Richardson introduced me to the idea of technical debt, (term was coined, like so many other terms, by Ward Cunningham) which I think is a pragmatic way to cut through the philosophical differences in this argument. But in the interest of carrying on the debate, and because it’s the weekend, I’ve decided to (perhaps) add some fuel to the fire. Please don’t read this at work.

The gist of the argument is about how much emphasis you should focus on robustness/code hygiene/maintainability in your code, even if it is unclear there is much business value in doing so. Essentially, if we consider impacts to budgets, deadlines, etc., and even in terms of its impact to your code (see Antipattern: “Yet Another Useless Layer”) — is it worth it? It’s very much a discussion of what software quality is and why is it important, which raises questions like:

Are robustness and business value mutually exclusive?
Does quality require rigor and conceptual cleanliness?
Is code hygiene a purely academic pursuit, or is there intrinsic value in it?

These are interesting questions. Atwood and Spolsky take what they feel is a more pragmatic position; Atwood explaining quality in terms of a Frank Zappa quote [paraphrasing] “Nobody gives a crap if we’re great musicians,” meaning that what matters is ultimately what is delivered to the customer. He explains further that “Quality is just another axis” — another set of competing concerns for your development time and interest. Spolsky’s comments constitute a self-professed rant that there is a thread of zealotry in the OO community around TDD. It reminded me a lot of what Cedric Beust has argued in reference to what Jim Coplien has debated with Martin himself. While Spolksy could be playing devil’s advocate, or could have been looking to start a “blog fight” (already popping up in comment threads) I think he could have gone about it in a more pragmatic way. While Beust does paint Martin as a zealot as well, at least his main point didn’t portray unit testing as just short of completely useless; rather, he is one of the creators of the popular TestNG framework:

“Tests first” or “tests last” is unimportant as long as there are tests.

I might be wrong, but I even remember reading a section of Clean Code in Borders last week and essentially reading Beust’s point in Martin’s book. It stuck out in my mind after watching his debate with Coplian. But I digress.

Before going further, I wanted to point out how much this debate reminds me of From pirate dwarves to ninja elves…, which I believe is a great way to classify personality types — especially those of people writing code. We know for sure that UncleBob falls into the Ninja-Elf quadrant. He thinks practicing TDD is a professional responsibilty and lays out his own definition for TDD in Clean Code. I think this is the very definition of a Ninja-Elf. My personal leanings are toward that quadrant as well. When you are innundated with Dijsktra, the ulitmate Ninja-Elf, in school, the following quote really sticks with you:

I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself “Dijkstra would not have liked this”, well, that would be enough immortality for me.

But there are people whose opinions I respect with Dwarf-Pirate leanings, too. Obviously Atwood and Spolsky lean in this direction (though they may not fall directly into that quadrant). I’ve heard some others that I respect espouse the same opinion as Spolsky; Gavin King, for example, I’ve heard him say, “The types of bugs that I introduce usually aren’t caught by a unit test.” He wasn’t as over the top in his argument, he simply explained that he prefers integration tests. And I don’t think you’d hear any of the people mentioned in this post say that they never write any tests. For a great argument from the ultimate Pirate-Dwarf see Cal Henderson’s normalized data is for sissies (slide #27); it is pretty entertaining and compelling when scalability is of utmost concern.

I think Atwood’s argument ultimately came down to championing the idea of continuous production; that being able to respond to change or bugs found and having a quick no-brainer deployment process is the Zen-like state you’d like to get to. But the idea of getting there is that it comes out of some notion of continuous integration, which is predicated on the idea of testing. Henderson himself makes this very argument (I believe in this talk, but perhaps in another). You need to trust your team enough to get changes and fixes out to address problems quickly, and be smart about what you spend time on. Testing is great and if you can find people that can test their code well and be productive, that’s awesome. But Henderson’s point is those people are extremely hard to find and retain.

All this goes back to the old question, is producing code an artistic or engineering practice? (Interesting that Atwood supported his comment with a Frank Zappa quote about art.) Obviously you need a talented and cohesive team to be able to make it work either way. I think the answer is it has to be a little bit of both. You’ll need some measure of creativity, some degree of engineering aptitude, also strong analytical skills, and to succeed in a business environment, some acumen in decision making and managing (at the very least your own time).

The fact is, though, that we’ve come leaps and bounds in terms of being able to efficiently produce these tests, and balance their production and maintenance out with constraints, business expectations, budgets and deadlines. And it can fuel your creative side, too.

As for professional responsibilities, I definitely wouldn’t recommend trying to write code without at least some tests if you expect anyone else to have to maintain your code. If you’ve got a close knit team and an overwhelmingly urgent need to deliver untested code (and are of the Pirate-Dwarf persuasion) then go for it. But that being said, I’d say I agree with Martin and Jared Richardson that argue it’s a professional responsibility to not take on the technical debt of untested code. Of course, if tests mean you can get maintainability (and other -ilities) along the way then I think that you’re well on your way to a quality product.

One final way to look at this: would you say it’s better for your team to take the view that code is innocent until proven guilty, or guilty until proven innocent? In the interest of skepticism, considering the teams that most developers “in the trenches” have to work on, and how far we’ve come in making testing easier and more efficient, I’d need a very strong team to make the assumption that all they code they write is innocent. We all make mistakes. I believe this is also brought up in Clean Code.

Ultimately the message Atwood and Spolsky send in their Stackoverflow podcast is that unit testing and efforts to support it are not a silver bullet. Personal slights aside (“I don’t think these people write very much code.”) they have a point — and Martin agrees in his blog post. But I think it took them a long time to make that point which is certainly no great revelation. In the end, I did not feel they explained a whole lot about what the right approach to quality is, but communicated their distaste for an attempt (especially if accepted dogmatically) that aims to do so. I can relate to this, and agree you must treat what you read, hear and are taught with a healthy dose of skepticism. Martin’s ideas may seem dogmatic on the surface but I don’t think it’s fair to paint him in that light. If you really read what he writes, I think he realizes that he is a voice many people are listening to, and works hard to say what he thinks is the right. Martin defends a style of development that favors more rigor and discipline than many others feel is necessary, but in an industry that can be categorized by its lack of discipline, I can’t do much but respect him for that.

16 Apps That Lessen TEH SUCK of Web Development in XP

Chris Wash — Thu, 22 Jan 2009 00:43:48 +0000

Update: Sysinternals puts out some great developer friendly tools. They come in handy!
Update #2: I’ve made the switch to using Launchy over DOMercury.

Working on Windows XP is unavoidable at my job. While it’s not my favorite environment, I’ve found a decent baseline of software tools to augment the barebones OS that can get me to a place where it isn’t that bad. Note, I’m not including any tools for doing off-development related things, anything development related that is on the web or any cool plugins for any of these programs.

Here is what I need, in roughly the order I download them:

Firefox – I open IE, download Firefox with the purest intentions never to open IE again. Of course, my job gets in the way. I’ll save all the addons for this I install for a rainy day.
cygwin – first thing I do after making necessary LAF adjustments and installing Firefox. I don’t know how some people can survive without a robust command line… at the very least find, grep, sed, xargs. Also, if you don’t know what Ctrl+R does in Bash, check it out immediately.
Google Desktop – in lieu of not having Spotlight or anything similar, I set this to work early indexing
Eclipse – there is so much I use Eclipse for. Always one of my first downloads/installs even if it’s not needed immediately. Contains TCPMon, a Diff/Merge tool, great refactoring support, and about a million plugins to do many development tasks you’ll inevitably need to do (or want).
TCPMon – Whether you use Eclipse’s or some other, track this down and figure out how to use it. (HttpFox is great, but it can’t capture requests you make outside of the browser. Sorry, we’re not supposed to be talking about Firefox extensions, I know.)
Pidgin – best F/OS IM client out there for Windows (and other platforms). You can do some crazy stuff with Jabber, ladies and gents. But that’s another blog.
WinSCP – I don’t need to FTP or SCP files everyday, but when I do it’s usually easier to do it using WinSCP, and I can save my connection information incase I need to do something similar later.
PSPad – currently my favorite Windows-based “barebones++” text editor. In addition to the “coder-style” basics, a neat trick is that you can launch hyperlinks or filepaths by selecting and right-clicking.
vim – …Because none of these editors are perfect, though, I always keep ole’ vim on hand incase I get annoyed with PSPad. Honestly, I find myself in it just as frequently.
WinMerge – best F/OS Windows diff tool I know of – can compare directories which you can’t get the Eclipse merge tool to do.
SoapUI – general swiss army knife for anything related to web services. (Contains TCPMon, too.)
Squirrel – Ditch the Toad, go F/OS. Well, there is a free version of Toad but it can’t compete. As Jack White says, “Be like the squirrel.” Does whatever you want to a Database. Any database (well, almost). Written in Java, communicates using JDBC. Driver manager is a good way to get correct JDBC connection strings if you ever forget or can’t seem to get one right.
CommandBar – Found this mentioned in the Productive Programmer as a way to marry an Explorer and Cmd window. Comes in handy.
clcl – Another Productive Programmer recommendation for a simple multiple clipboard manager.
git – while I don’t always need this, I have been using it more lately because the version control software I have to comply with (eventually) on my current client sucks so mightily. I’m using git for day to day development and then I create a repo to interoperate with Harvest when I need to. (Be thankful you don’t have to use Harvest.)
DOMercury – Recent find that provides a Quicksilver-like launcher for Windows. It also includes an Alias manager. A priceless easter egg: ‘wtf’ launches IE. This sold me immediately. I’m not sure how well it keeps itself indexed, but I usually install it after everything else to keep it simple.

What am I leaving out? What kinds of things do you need to make your time in XP bearable?

24ways

Chris Wash — Mon, 01 Dec 2008 15:08:37 +0000

I can’t believe it’s already December! I came across 24ways last year and thought it was a neat concept: an ‘advent calendar for web geeks’ – take a look! They had a pretty good variety last year and I’m expecting some good things this year.

New Apple Wireless Keyboard

Chris Wash — Fri, 01 Aug 2008 18:55:02 +0000

On Tim Bray’s recommendation, I just picked up a new Apple Wireless Keyboard:

So far, it seems like a good choice. As mentioned in Tim’s post, I notice my typing speed has dramatically increased immediately, when compared to the built in keyboard, or the stock Dell keyboards I’ve been typing on when not at my Mac recently.

I didn’t think the num pad warranted the extra space it’ll take up when I carry it around with me. The super big command key doesn’t concern me quite as much, because I’ve gotten used to slipping my left thumb down to hit it from hovering over the spacebar, and it’s easier/more natural to do that on this keyboard compared to the one built into the MBP.

And this all goes without saying that the wireless features are a big plus. Whenever you sit down to do something, having to plug in an extra wire is nothing short of a pain in the ass (not to mention taking up valuable port space on my precious laptop).

So far I’m pretty happy with the purchase. If my opinion changes, I’ll let you know, but the spot judgement is that it’s exactly what I was expecting.

Help the Good Guys

Chris Wash — Thu, 31 Jul 2008 19:22:18 +0000

I think it’s important to support and give back to products and efforts that are high quality and enhance your productivity, happiness, or everyday life. A List Apart, a web published magazine “for people who make websites” was the first feed I remember adding to my feed reader. It definitely falls into this “need to give back” category for me. Their articles have a web design/development slant, and are written in a consistent, succinct, repeatable fashion. It’s a successful site, and I applaud its efforts.

If you didn’t know about ALA, well now you know. If you do know about them, give something back by participating in their survey.

Up And Running

Chris Wash — Thu, 14 Feb 2008 20:39:01 +0000

Reinstalled WordPress. I’ve been a little frustrated with other blog efforts that I’ve been roped into in the past few years and have decided that this is as good a place as any to just get stuff written down. And there’s really no good reason not to – so here’goes!

cwash into software » Meta/Blog

What I’d Tell Myself About Design If I Were Just Beginning

More Related Content

RubyRX NC

Career 2.0

Dr. Nil

HAML and SASS

Build Up Vs. Build Down

It’s All Been Done Before…

More Related Content

In response to Stackoverflow #38/”Quality Doesn’t Matter That Much” — Jeff and Joel

More Related Content

16 Apps That Lessen TEH SUCK of Web Development in XP

More Related Content

24ways

More Related Content

New Apple Wireless Keyboard

More Related Content

Help the Good Guys

More Related Content

Up And Running

More Related Content