Will Software Craftsmanship change with new Domain Workbenches
:bob
Intentional Domain Workbench. This workbench promises a revolutionairy
new way of enabling domain experts to express their intent in a domain
language of their choice (and making) that will result in an
executable system.
The demo can be seen at http://msdn.microsoft.com/en-us/oslo/dd727740.aspx
I am curious to know what you think how our profession and the
Software Craftsmanship aspect of it will change because of this tool
and for instance Jetbrains's upcoming Meta Programming System.
Adewale Oshineye
explain how these sorts of systems were tackling the essential
complexity rather than the accidental complexity of software
development.
The problem is seldom that domain experts don't have a good way of
expressing their intent but more that they need help minimising the
ambiguity of their intent as well as resolving the complexities
inherent in their domain. Then they have to take that unambiguous
(more or less) expression and find a way to reify it within the harsh
constraints of computer science and physics.
I suspect that in 10 years time we'll have forgotten about Intentional
and we'll be talking about yet another silver bullet whilst our
existing toolsets continue to steadily evolve.
P.S.
I assume everybody here's read Fred Brooks's No Silver Bullet.
P.P.S
I suspect that in a couple of decades everybody will be a programmer
but only some of us will be professional programmers in much the same
way that most people can type a Word document but only a few of us
get paid to layout magazines.
2009/4/23 :bob <bob.gro...@gmail.com>:
Raoul Duke
> and we'll be talking about yet another silver bullet whilst our
> existing toolsets continue to steadily evolve.
but hopefully Intentional is still a nice new tool we can all benefit
from, even if it isn't a silver bullet.
LudovicoVan
> Recently Intentional Software gave the first public demo of its new
> Intentional Domain Workbench. This workbench promises a revolutionairy
> new way of enabling domain experts to express their intent in a domain
> language of their choice (and making) that will result in an
> executable system.
>
> I am curious to know what you think how our profession and the
> Software Craftsmanship aspect of it will change because of this tool
> and for instance Jetbrains's upcoming Meta Programming System.
Seriously, I for one have been dreaming something like this for the
last ten years at least. There is no silver bullet, OK, but in the
sense that we always keep improving. Here I would envision the so long
waited for fifth (or is it sixth?) generation of languages.
-LV
Robert Hanson
> Software Craftsmanship aspect of it will change because of this tool
I am not sure I get it. Maybe I am missing something, but the domain
expert still needs to explain the domain and you still have to write
code.
If anything, I am turned off by their product. All I saw was 2000
lines of code in a single file, and a fairly unintuitive editing tool.
> There is no silver bullet
Agreed.
A few years back I was shown a tool called E.Piphany, an incident
management/help desk tool. The tool used a language called BIML,
which was designed to allow domain experts (business people) program
it by using Visio. You would drag components into the diagram, where
each component performed a task, then you would set their properties
and link them together. You would do this 3 times, once for the model
layer, once for the controller, and once for the view. You would then
deploy your diagrams.
The problem is that there were 500 components to choose from, and you
had to understand what each of the component properties meant. In the
end it required a programmer to use the tool, and the programmers I
spoke to felt that it hindered them. I recall that it was taking them
a week to roll out even the smallest of changes.
So I guess what I am saying is that tools are ok, just as long as they
don't get in the way of getting things done, and I question if this
tool is a help or a hindrance.
Rob, the Skeptic
http://www.google.com/profiles/IamRobertHanson
Curtis Cooley
Agreed as well. Business has been trying to eliminate the programmer
since the first development project. The UML to code nirvana wasn't
that long ago. Did we forget already?
--
Curtis Cooley
curtis...@gmail.com
===============
Once a programmer had a problem. He thought he could solve it with a
regular expression. Now he has two problems.
Francesco Rizzi
Agreed as well. Business has been trying to eliminate the programmer
since the first development project. The UML to code nirvana wasn't
that long ago. Did we forget already?
Nonetheless, thanks for the link to the video; I'll share at work and see if the team wants to explore this new tool.
On another note, I think "Business has been trying to eliminate the programmer
since the first development project." might be a bit of a harsh statement. I think I know where you're coming from - as a developer myself, I've wondered at times if that's what's going on.
However, I think things are a bit different:
1~ the day 'business people' get the 'programmer' out of the picture will be the day 'business people' will realize why they need and *want* 'programmers' in the picture. There's a reason why we're in the work position we are: it's (for most) what we're best suited to do. Conversely, the so-called 'business people' are best suited at their job. The average 'business person' I met in my career would run away screaming from things the average 'programmer' deals with on a daily basis (and some might even enjoy). The average 'programmer' i met in the same period would do anything (even programming) in order to avoid the tasks 'business people' handle quite well daily.
2~ additionally, I think these tools/processes/ideas/whatever-you-see-that-is-aiming-at-'eliminating the programmer', are actually tools that aim at A) improving the quality of the product by bridging the gap between the 'programmers' and the 'business people', and B) freeing the 'programmer' from "accidental complexity" and being therefore able to focus on the "essential complexity" of the solution under development.
That's not to say that the tools have already achieved a comfortable level of success in their goal.
F.O.R.
LudovicoVan
> > I am curious to know what you think how our profession and the
> > Software Craftsmanship aspect of it will change because of this tool
>
> I am not sure I get it. Maybe I am missing something, but the domain
> expert still needs to explain the domain and you still have to write
> code.
business guys, I think analysts...
-LV
Dave Hoover
I think that's a good point. If programmers from 30 years ago looked
at my typical day today, I bet they would think I was more of an
analyst than a programmer. The high level code that I get to work
with typically keeps me very close to the domain language of my
customer. As I was just telling a new acquaintance here at CITCON,
the problems I'm generally solving aren't related to computer science
and optimizing milliseconds, they're translating my customer's desires
into executable software. I imagine that this translation is much
easier today than it was 20 years ago due to highly productive and
expressive languages like Ruby.
Dave Hoover
//obtiva: Agility applied. Software delivered.
Simone Busoli
IOW, while a developer could well change its role to become, say, a business man, it's very unlikely that a business man would ever become and be able to be a developer.
Adewale Oshineye
> One thing that I've been thinking about for quite some time now is that
> given all the roles one could cover in any company, the developer/technician
> is one of the few that you cannot learn just by doing it like you would do
> any other job.
> IOW, while a developer could well change its role to become, say, a business
> man, it's very unlikely that a business man would ever become and be able to
> be a developer.
I don't understand this. What would stop a sufficiently motivated
business person from signing up for courses, reading some books,
writing/reading a lot of code and joining a supportive development
community that's willing to train them up?
Simone Busoli
listed. Do you think that being a business/hr/recruitment/whatever
person requires you to constantly practice, read, collaborate, work in
open source, teach? In my experience, it doesn't, and it's common
sense that you're not required to do so. Most of what you do to do
your job better is, well, do your job. For developers at times it can
even be the opposite, do many things on your free time in order to be
a better developer at work.
2009/4/25, Simone Busoli <simone...@gmail.com>:
--
Inviato dal mio dispositivo mobile
Cory Foy
Actually the recruiters I know work constantly to improve contacts, network, and generally do things outside of work to make them better.
My wife did HR, and she also spent lots of time improving who she was by participating in conferences, learning about new HR laws, etc.
Craftsmen are available in any industry. And I bet they are conceptually similar. We just call them excellent employees everywhere else.
Cory
(from mobile)
-----Original Message-----
From: Simone Busoli <simone...@gmail.com>
Date: Mon, 27 Apr 2009 01:28:29
To: <software_cr...@googlegroups.com>
Subject: [SC] Re: Will Software Craftsmanship change with new Domain
Workbenches
Curtis Cooley
and says, "Teach me to be an engineer. I don't care if it takes all
day."