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”
In my previous post, I set out three problems that I believe software crafters worldwide should work on in the years to come to fulfill the promise of “raising the bar”. This is a quick update on its aftermath.
Continue reading “The aftermath of ‘the three problems’ blog post”
In 1900 David Hilbert challenged the best mathematical minds to solve 23 problems. This set of problems has influenced the mathematics of the next century, leading to surprising discoveries. Probably the most shocking discovery was that axiomatic systems have inherent limitations.
Today, a different set of very bright people face a new era. 7 years of Software Craftsmanship has led to changes in the world of software. I can travel almost anywhere in Europe and find a community connected to software craftsmanship. People from the community authored books and articles. We stay in touch all the time thanks to modern technology such as slack, twitter, facebook and meetup. Local communities and companies organize conferences. And a brave member of this community started a newsletter, trying to guide us through the news in the field. We share what we love and we love to share.
Continue reading “Three Problems For The Next Era of Software Craftsmanship”