On 05/08/2014 08:19 AM, Grzesiek Gałęzowski wrote:
It's Alexandru :) or simply Alex. No problem Grzesiek ;)
I like the sketch you provided, In my opinion, it contains
some very important factors to becoming a great craftsman. As
requested, I'd like to question two of the points you make for
Thanks for your support.
- Gather a team of
craftsmen that will not only work together but
also learn and grow together over the long-term.
what do you mean to "gather"? At team level? Product
level? I work in environment where a single product
consists of many subsystems and all work through the
release. Each subsystem is then divided into several
feature teams. I am a developer, which is not always the
corresponding role of architect in building. I view
architect as someone who creates the technical vision
and ties things together. As a developer, I am usually
expected to execute someone else's vision (not that I
don't have a say, it's just that I often do not play the
lead role). Thus, I think my abilities to gather are 1)
less formal - I do not have power to command people nor
can I choose who I work with - have to use my abilities
as a change agent to transform the environment I was
given. 2) limited - Even when I manage to transform my
team into a team of craftsmen, I am still influenced by
people outside it, who may not value the craftsmanship.
Thus, I think merely gathering a team of craftsmen is
not enough - it must be a team that shares their skills
extensively and promotes discussion around those skills.
You are right, this is unclear. The simple reason is that I don't
exactly know what it means yet :).
I think "gather" means to me two things:
* I am fortunate to have the freedom to hire and teach developers
and the privilege to influence the values of the organization. It
won't be easy, but at least I have this opportunity.
* Finding the right developers that aren't working with me but share
some of my ideas and are willing to discuss and challenge them.
That's part of what I hope with this message.
working software that delights users and customers. This is not only the job of the graphical
designer, interaction designer, product owner. It’s
also my job as a developer.
I am having some issues understanding in what way should
my work delight users. I can think of: application
performance, responsiveness, throughtput and reliability
(e.g. lack of bugs). I think the only way I can delight
customers and users with e.g. good design, is when I can
deliver new features fast and reliably. Am I missing
I agree with your idea that, in general, delivering new features
fast and reliably is part of it. I believe there's more. As software
developers, we can sometimes influence the way the application
behaves by looking at the application from the user perspective. For
example, I never start to work from user stories. I define a
complete scenario from the user's point of view, and ask questions
such as: Could this be made simpler for the user? Could we skip a
As a recent example, we recently implemented features related to a
doctor that consults a patient and introduces data in the
application. Instead of considering the stories (as a doctor I want
to prescribe a drug so that ...), we discussed about the different
types of consultations: temporary problems (such as cold or flu),
acute problems and chronic problems. We then discussed with the
customer these specific scenarios, thus discovering how to simplify
the UI and the interaction between the user and the software. This
extra step is what I'm talking about.
- Write only the technical and functional
documentation that is useful. Favour
working software over detailed diagrams. (Gaudí had to
work with real materials and build 3D models; we are
lucky to work with code, easier to sculpt than stone –
when written so that it’s easy to change)
What do you mean by "working with code"? Do you mean
prototypes? Automated tests (e.g. ATDD)?
Self-documenting code? All of it? Are you considering
useful any functional or technical documentation that is
not about "working with code"?
I'm merely saying that stone is harder to sculpt into
the right form than code. As for functional documentation, I
believe functional documentation that's not executable is bound to
become obsolete very quickly, so I prefer some form of executable
. Most technical documentation can be replaced
with good coding practices - writing simple code, using consistent
and clear naming and so on. However, some technical and functional
documentation is needed; I've used for example, diagrams of the
functional scenarios and various types of architectural diagrams
depending on the case. The key here, from my point of view, is to do
the minimum documentation, but the most useful, depending on the
Thanks a lot, I loved your questions!
On Wednesday, May 7, 2014 9:41:27 AM UTC+2, AlexBolboaca