I’m very interested in applying general design principles to software design. I am convinced that software design is just design applied to a specific material: code. Since design as a discipline is thousands of years old (the pyramids were designed) while software as we know it today is only a few decades old, I find it obvious that there’s a lot to learn from it.
Part of my exploration was to understand more about the design principles other designers use. One very common principle is the “white space” or “negative space”.
Continue reading “Applying the design principle of “white space” to code”
There are many ways to look at programming. Some people do it to make a living. Others want to see things working fast and hack it away. Others believe in building a profession from programming and thus seek practices and submit themselves to challenges that expand their views.
It’s very easy to pass judgement on some of these attitudes. I will not do that. People need to live, to support their families, to feel good while working. If anything, we should be happy that we, programmers, have opportunities other people don’t.
Instead, I will present my view on programming. A view shaped by a 40 years love story and a few key events. A view that I feel is shared by a very small minority of the community. I am encouraged to present this view by tweets from the recent DDD Europe conference.
Here’s my view:
I am a designer who happens to use code
Learning from other designers
I am a designer because I build upon the tradition, the practices, the techniques and the principles of design, a discipline that’s thousands of years old. I do this by reading, analysing and adapting techniques used by other designers.
Continue reading “I am a designer who happens to use code”
“Design” is an overloaded term that causes confusion in software development. It has at least three meanings: design as result (as in “the design of the application is easy to change”), design as process (as in “I designed it using Test driven development”) and design as aesthetics (as in “I love this design”).
A clear vocabulary is the sign of a mature profession. Therefore, as an effort to advance our profession, I propose fixing the confusion using a more precise set of terms. You’ll find a glossary at the end of this blog post.
Continue reading “An Attempt At Clarifying The “Software Design” Vocabulary”
Every once in a while, I have conversations with people about what really is TDD. Since I built a certain knowledge on the topic in time not only by using it but also by explaining it to others, I decided to write this article that details my definite view on what TDD is. I hope you’ll find it useful.
This is a long article. If you’re in a hurry, this is the 5 minutes version:
Continue reading “What Is Really TDD?”
This is a long due blog post. I wrote it before the series of blog posts on Usable Software Design (first, second and third) but due to a strange series of events (including totally forgetting that I wrote it) is published after them. In a sense, the ideas from this blog post are superseded by the series on Usable Software Design. In many other senses, it contains a ton of background information useful to people who want to get a better grasp of Usable Software Design.
My recent blog post, “The craftsman I would like to be” generated interesting reactions both from people I know and from complete strangers. I’m glad to see that the software craftsmanship communities have reached the point where we can discuss such matters of high importance for the movement and for members such as myself.
I have to admit that I expected a bit of controversy when writing this post. After all, it’s still unclear in my mind and I’m proposing certain things that I know are impossible. That’s the point of an ideal, after all.
What I didn’t expect was the amount of controversy met by my views on software design. Here’s the story.
I proposed the topic called “What is good software design?” at the fishbowl session at SoCraTes UK, and I was lucky to have it picked by the majority of the participants. The discussion was very interesting and unexpected. Instead of talking about the things you would consider about software design (SOLID principles, design patterns, differences between the OO and functional paradigms etc), the discussion drifted towards the humanistic point of view on design.
“When is the last time you saw a software design that was not only useful, but amused you?”* was the (I assume) intentionally provocative statement that sparked the discussion. Continue reading “User-Centric Software Design”