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.
In all the years I was at TW people like Martin Fowler could never
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.
> 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.
> 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.
but hopefully Intentional is still a nice new tool we can all benefit from, even if it isn't a silver bullet.
On 23 Apr, 08:54, ":bob" <bob.groenev...@gmail.com> wrote:
> 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.
The tools by themselves do not solve problems... ;)
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.
> 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.
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.
On Thu, Apr 23, 2009 at 9:02 PM, LudovicoVan <ju...@diegidio.name> wrote:
> On 23 Apr, 08:54, ":bob" <bob.groenev...@gmail.com> wrote: >> 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.
> The tools by themselves do not solve problems... ;)
> 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.
>> 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.
> 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.
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.coo...@gmail.com =============== Once a programmer had a problem. He thought he could solve it with a regular expression. Now he has two problems.
On Fri, Apr 24, 2009 at 11:13 AM, Curtis Cooley <curtis.coo...@gmail.com>wrote:
> 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?
I tend to agree with the reaction many seem to have: there's no silver bullet.. this sounds like a good idea, but past experience taught me the Graal might not be hiding behind the next corner. 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.
On Fri, Apr 24, 2009 at 7:12 PM, LudovicoVan <ju...@diegidio.name> wrote:
> On 24 Apr, 15:59, Robert Hanson <iamroberthan...@gmail.com> wrote: >> > 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.
> Sure, but higher level code. When I see this stuff, I don't think > business guys, I think analysts...
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.
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.
On Sat, Apr 25, 2009 at 01:08, Francesco Rizzi <francesco.ri...@gmail.com>wrote:
> 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.
> 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?
I think that being a developer requires much more than what you've 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.
> 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.
> On Sat, Apr 25, 2009 at 01:08, Francesco Rizzi > <francesco.ri...@gmail.com>wrote:
>> 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.
Date: Mon, 27 Apr 2009 01:28:29 To: <software_craftsmanship@googlegroups.com>
Subject: [SC] Re: Will Software Craftsmanship change with new Domain
Workbenches
I think that being a developer requires much more than what you've
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.bus...@gmail.com>:
> 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.
> On Sat, Apr 25, 2009 at 01:08, Francesco Rizzi
> <francesco.ri...@gmail.com>wrote:
>> 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.
On Sun, Apr 26, 2009 at 4:28 PM, Simone Busoli <simone.bus...@gmail.com> wrote:
> I think that being a developer requires much more than what you've
> 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.bus...@gmail.com>:
>> 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.
>> On Sat, Apr 25, 2009 at 01:08, Francesco Rizzi
>> <francesco.ri...@gmail.com>wrote:
>>> 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.
> --
> Inviato dal mio dispositivo mobile
-- Curtis Cooley
curtis.coo...@gmail.com
===============
Once a programmer had a problem. He thought he could solve it with a
regular expression. Now he has two problems.
|
