The user of software design is the developer. Here's how this will change your designs

[AlexBolboaca]

Hi fellow craftsmen,

I wrote a new article about software design that I hope you will find useful: Usable Software Design.

The article has a backstory. Two weeks ago I wrote an article, 4 Ideas to apply for better software design, that explored a few ways to improve the way we design software. Encouraged by the feedback, I decided to explore it a bit more.

I'm proposing a paradigm change in software design: it is not userless but the user is the software developer. Using techniques from usability in software design will ensure that new developers in the team become productive faster and that most common tasks will be faster to finish. The article also touches the surface of a few techniques that will help achieve more usable software design.

Please let me know if you find these ideas useful. I have much more to say about this topic, but I'd like to know if there's interest.

Thanks,
Alex

[Gabriele Lana]

On Thu, Feb 5, 2015 at 10:27 AM, AlexBolboaca <alex...@gmail.com> wrote:
> Hi fellow craftsmen,
>
> I wrote a new article about software design that I hope you will find
> useful: Usable Software Design.
>
> The article has a backstory. Two weeks ago I wrote an article, 4 Ideas to
> apply for better software design, that explored a few ways to improve the
> way we design software. Encouraged by the feedback, I decided to explore it
> a bit more.

Hi Alex,

I didn’t read (yet) the blog posts, just skimmed, but I’m wandering
how you would relate your ideas to the “old” concept of "Software
Habitability" (http://c2.com/cgi/wiki?EndUserHabitability)

Just curious because they seem closely related if not the same thing

--
Gabriele Lana
https://github.com/gabrielelana
https://twitter.com/gabrielelana

[Sleepyfox]

Hi Alex, 

I read the blog post, I think you're on the right track. Have you read Jack W. Reeves' article "What is Software Design?"

http://www.developerdotstar.com/mag/articles/reeves_design.html

or here for a PDF containing all three essays:

http://www.developerdotstar.com/mag/articles/PDF/DevDotStar_Reeves_CodeAsDesign.pdf

@sleepyfox

--

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsma...@googlegroups.com.
To post to this group, send email to software_cr...@googlegroups.com.
Visit this group at http://groups.google.com/group/software_craftsmanship.
For more options, visit https://groups.google.com/d/optout.

[Alexandru Bolboaca]

Hi Gabriele,

Thank you for your message.

I admit that it's the first time I hear about user habitability. I just
read the link you included, and the two concepts look indeed very
similar. It wouldn't be the first time a past idea was revisited.

I have however two issues with the idea of Software Habitability, as I
understand it now:

1. It doesn't specify strongly the fact that a software developer is the
user of software design. We've always had the problem in this industry
that the user of software doesn't care how the software is structured.
In writing the articles, I felt it was important to clearly state that
software design is not userless.

2. I couldn't find any practical ideas on how to achieve Software
Habitability. There seems to be a slight connection with interaction
patterns, but it's very little to work with. On my part, I did provide
the first few ideas on how to achieve more Usable Software Design, and I
plan to explore this topic some more.

This doesn't mean I'm dismissing the idea of Software Habitability. One
the contrary, I am open to learning from the past, because I feel this
industry reinvents the wheel every 5 years or so. If anyone can point me
to more materials related to it, please do.

Kind regards,
Alex

[Alexandru Bolboaca]

Hi Nigel, (or @sleepyfox :)

Thanks for your message, and thank you for pointing me at the essays.

I skimmed them and I found traces of my personal struggle with understanding software design. After all, in many domains "design" means a set of diagrams. It took me a while to understand that sometimes, design also means building a prototype. Basically, design means anything that you can do to prove that something works / is appealing / is useful. It can be anything from a drawing, computations, a set of diagrams to a scaled model.

I always felt comparing software with other domains was tricky. Building bridges is a fundamentally different activity from drawing them, or from computing the forces so that they withstand the right load. Turns out, I know at least one building architect who avoided at all costs drawing things and favoured building detailed scaled models. He gathered a team of builders and was present at all phases of the construction. His name was Gaudì, and he built a lot of world-renowned buildings in Barcelona.

I see software design as building prototype after prototype to prove that you're on the right track. And isn't it great that the prototype is the working application? I'm sure Gaudì would have rejoiced at the idea that his scaled model could be magically transformed into a real building; unfortunately, bricks and mortar doesn't have this benefit.

I hope I haven't been rambling too much. It's been a long day. I'll read the essays carefully, thanks for pointing me to them.

All the best,
Alex

PS: How many such gems are hidden in the history of this industry? I wish we could create a museum for them, they're worth preserving and studying.

You received this message because you are subscribed to a topic in the Google Groups "software_craftsmanship" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/software_craftsmanship/LaTsy8zVTqg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to software_craftsma...@googlegroups.com.

[Raoul Duke]

(top posting because my thoughts are not paragraph-by-paragraph :-)

Yet computing has the power to change things. We should be
interactively designing bridges in an IDE that shows us all the
physical data and characteristics, to the best of our ability to
project & simulate. So the old distinctions of drawing vs. scale model
building vs. back of the envelope physics math calculations should
really all be collapsed down into a coherent, holistic unity. I have
no idea if that is how bridges are currently approached. I'm sad if it
isn't.

I wish we had it for software. When I'm coding in an IDE (you know,
like Emacs ;-) it would be great for the system to be running
simulations and tests of all my stuff automatically all the time, and
telling me, "Hey, bozo, you might not want to use a HashMap there, but
a LinkedList" or whatever else. It should be telling me how big the
final executable will be on various platforms; how fast it will run;
how complex the state space is (each boolean doubles it); how much
code coverage there is from the tests; anything and everything we can
come up with that might be useful to be able to know "ahead" of time.

[Alexandru Bolboaca]

Hi Raoul,

I agree. We need more feedback in software development.

Have you seen Bret Victor's talk on feedback -
http://vimeo.com/36579366? I highly recommend it if you haven't. I think
it would be a good start for a better IDE. It's also an amazing talk.

Alex

[Raoul Duke]

oh yeah, of course :-)

that stuff is great, but also depressing since we are apparently so
far away from it all.

[Gabriele Lana]

On Thu, Feb 5, 2015 at 6:59 PM, Alexandru Bolboaca <alex...@gmail.com> wrote:
> Hi Gabriele,
>
> Thank you for your message.
>
> I admit that it's the first time I hear about user habitability. I just read
> the link you included, and the two concepts look indeed very similar. It
> wouldn't be the first time a past idea was revisited.

No, it wouldn’t be the first time, but the fact that you came out with
something so similar without knowing it, for me it’s a huge
confirmation of the idea

> I have however two issues with the idea of Software Habitability, as I
> understand it now:
>
> 1. It doesn't specify strongly the fact that a software developer is the
> user of software design. We've always had the problem in this industry that
> the user of software doesn't care how the software is structured. In writing
> the articles, I felt it was important to clearly state that software design

> is not useless.

> 2. I couldn't find any practical ideas on how to achieve Software
> Habitability. There seems to be a slight connection with interaction
> patterns, but it's very little to work with. On my part, I did provide the
> first few ideas on how to achieve more Usable Software Design, and I plan to
> explore this topic some more.

I think the term was used for the first time by Richard P. Gabriel in
his book “Patterns of Software” (great forgotten book BTW) and then
used by Alistair Cockburn as a foundational concept for “Crystal
Clear” http://en.wikipedia.org/wiki/Crystal_Clear_(software_development)

The Cockburn's work contains some rather practical advice

> This doesn't mean I'm dismissing the idea of Software Habitability. One the
> contrary, I am open to learning from the past, because I feel this industry
> reinvents the wheel every 5 years or so. If anyone can point me to more
> materials related to it, please do.
>
> Kind regards,
> Alex