Now how did that saying go… the best theory is the most practical one, or something like that…

Anyway, I’d think simplicity and familiarity are important for this to succeed.

People who are unaccustomed to calculating sums and predicate logic when thinking efficiency and correctness of code, won’t use it.

On the other hand those who are accustomed to those will more likely use them to approach the said problems too.

To freely quote Sun Tzu… “Know yourself and know your enemy and you won’t lose a hundred battles”.

To get a change succeed the developers of the theory should take the “client” into account and cater to his/her appetite.

Just like in software engineering. ;)

To get complex solutions familiar to people, the education is of prime importance… but even education is not perfect, nor yield fast results.

So it can’t be counted upon to change the people the theory is made for such that they adopt it when it’s ready.

In good software development cycle, in my opinion, the client is part of the project from the beginning.

The same should be done with the developed theory, in my opinion.

I believe you have gotten the metaphor I’m using by now… you’re developing a theory ~ you’re developing excellent and useful software for a client.

I don’t think I need continue anymore; you can fill in the rest. :)

So the question is… how would you make great and useful software for a client?

And when you’ve answered that question to yourself, apply it to practice.

To know your client, you can use all the information you can get from those who research our clients (probably social psychology, psychology, anthropology..?) and from your own experience.

They’ll probably answer, if you ask.

They’ll feel themselves useful, which I think is what people want to feel. :)

It’s like team-work… (in my opinion) if everyone in a team is taken equally into consideration, everyone will also be backing up the results of the team.

And converse will happen if it doesn’t happen.

People want to feel they’re a part of the decision making process…

And the team we’re talking about is our industry, of course.

What can I say?

Keep your eyes open and if you see someone leaving out of the discussion, try to get them more into the conversation… to make them feel that they’re part of the team.

This is getting unclear at a fast pace, as is usual when I get tired, so I’ll wrap this up jsut by saying that consider this a software engineering challenge, where the client is part of the team and should feel he/she is part of the team… and apply your expertise.

You should do just fine and end up in a practical result, which is familiar and easy to the “client” and thus give a nice foundation for later developments. :)

What will make the everyday programmers even consider trying to develop their skills further?

In music, the audience will boo you out, if you’re not clearly good.

In software, if it’s “good enough”, no-one cares.

The client will not be interested in the code nor be capable of evaluating it.

Peer review outside companies won’t work because of trade secrets.

Peer review inside companies will remain inside companies and divert from others… causing conflicts when work-force changes.

With much change in work-force and plenty of time, the practices will probably consolidate to something common across all companies… the know-how becomes tradition.

Maybe mapping the skills and professional tendencies of the programmers and directing them to same teams?

Theory for that?

Just a few toughts, if someone wants to pick them up.

The discipline of Software Development rests (or should preferrably rest) on distinguished and established sciences such as Computer Science, Mathematics, Linguistics, System Theory, Social Psychology, Cognitive Sciences, Motivation Theory and probably a few more. The span is rather large and covers a broad range of university faculties. I don´t think adding something like “A Science of Software Engineering” to the list solves any real problem. The scientific part is there already.

In my view, what we need most in order to move on is Professionalism. A Professional stance is built on skill, experience and craftsmanship. This in turn rests on theory and subject knowledge, but it cannot be “taught” in the way you can teach theoretical knowledge. A scientific theory can be understood and “learned” if you have a good tutor or by reading a book. But the real insights that lead to a change in behaviour is based on personal experience, preferrably in active company with good role models or mentors. Without any theory the road to excellence will be very long and full of time consuming mistakes. With a good theoretical foundation the professional training will proceed faster and with a more predictable result. What I would like to see in this initiative is an effort to examine the theoretical foundation for different aspects of our profession and then discuss how we can best support the development of professionalism throughout the practitioning community.

Following an impulse from a previous posting, I would like to encourage a comparison to the discipline of music. No serious person would take a seat in the violin section of a professional orchestra after a three weeks summer class in swedish folkmusic. OK – you did take a few years lessons in school, but you didn´t really grasp the musical notation back then, so that´s why you go for a summer class. Do you really think of yourself as a professional musician after that endeavour? Thought not. But how come so many software developers lack the most basic skills to make them able to work as team members in a software development project? And I bet they get better payed from the start than most of our philharmonic members. If the solo flute is out of tune everybody suffers and she will hopefully be exchanged. If a cellist repeatedly ignores the conductor´s demand for a change in phraseing, he will not be in the next production of that conductor. Play down bow when the rest of your section plays up bow and your colleagues stop talking to you. There is a wealth of learned theory and internalised behaviour connected to the role of musician in the orchestral teamwork.

Why can´t we claim the same for our “profession”? At the moment I am trying – in the role as software architect – to implement use case driven iterative development in a new team with rather senior developers. I can see a whole bunch of reasons why this doesn´t work. Probably some of them relate to my own incompetence, but the main obstacle seems ro be the lack of a common understanding of how software is developed. Iterative development is how I have learned and prefer to work. These guys obviously prefer to work in other ways (but they fail to tell me how) and the project delivery is in danger. In the orchestra I as a conductor would know how to instruct a colleague based on our common understanding of “music making”. In this software project, in an organisation lacking support for a development process, I can only pray and hope these guys will ask before they do something really creative and original…. As you, Ivar, would say: “This is unsmart”.

I’m disturbed by the tendency of current SW practices, e.g. Agile, that appropriate past practices, wrap them up in new terminology without proper attribution, and repackage those practices as the answer to “everything”. And if you are sceptical, the standard response to reply with the epithet, “waterfall”. The latest fad is kanban – an utterly spurious adaptation from the Toyota Production System that treats requirements/work as if they were standardized units (with well-defined means and variances) that can be picked off a work queue. I wonder if the perpetrators of this movement would push the comparison as hard if they truly knew how it supported TPS objectives. (And the key word is ‘system’ in this context; not collection of processes that can be cherry-picked at whim.)

It seems to me that in the chase for the next new process, we forget that engineering takes place in the context of what is to be designed, e.g. PC software does not need to be as rigourous as Telecoms software and that should influence our choice of processes, tools and languages.

It’s a bit of a rant, but I have come to realize that software development is subject to more fads than management is. I think of Peter Drucker’s throwaway line about being referred to as a ‘guru’ – it’s only because ‘charlatan’ is difficult to spell.

Is EssUP/EssWork, the best part for me is not in the Practices themselves.

The best part lies into the kernel and the alphas (+lifecyles), the activity spaces, the areas (green, yellow, blue) and the gameboards.

Practices are secondary to that when you look at is as achieving outcomes. The kernel addresses outcomes, the Practices do address means.

I would rather focus on pushing the kernel concepts before doing any Practice evangelization.

We can coach almost anyone about a practice but we need to align teams and companies on the kernel principles and structures.

These days people are talking lean, Kanban etc. The Kanban thing at Corbis is just a pattern (in some project management practice) to use to manage the workload. The alpha is the backlog and the states of it are really more centered around moving the state of the alpha forward. Putting Kanban in place is perfectly coherent with the backlog concept in EssUP.

It aligns perfectly with a discussion I had last week when quoting my grandmother while running a project management course.

I quoted my grandmother saying “never mistake activity for progress” one of the participants put me on the spot by noting that I had quoted my grandmother 3 times in response to questions. He then noted that I was allegedly an agile type project guru and asked if we had learned much about running projects since my grandmother’s time.

I responded that we have spent a lot of effort learning (and sometimes relearning) many lessons. But we still haven’t gotten around to mastering the simple process of finding out what people need and then delivering a solution that meets their needs.

I would love to have a better response than that so I am very interested to see what comes next through spending the time to understand the core of the problem (of software development) rather than marketing a partial new solution which, if followed with discipline, will probably result in success.