Scientists/PhD/generators struggling with Product Development

[Tim Ottinger]

We have a team who used to do research and pass their ideas on to
development after.
It's not my team, it's the team of a lady whose team I coached once upon a time.

Now they're expected to build a product.

They're big fans of building models (state charts) and letting the
code be generated.

The generated code is ass.

The question is where to find the psychological triggers to turn them
from "got the right answer" to "built a sustainable product."

Any suggestions from my friends?


--
Tim Ottinger, Sr. Consultant, Industrial Logic
-------------------------------------
http://www.industriallogic.com/
http://agileinaflash.com/
http://agileotter.blogspot.com/

[Andreas Leidig]

Hi,

Bring them together with guys from operations. There they face similar problems: find the right answer. There the answer INCLUDES sustainability.

Cheers
Andreas

[Dale Emery]

Hi Tim,

> The generated code is ass.
>
> The question is where to find the psychological triggers to turn them from "got the right answer" to "built a sustainable product."
>
> Any suggestions from my friends?

In what ways is the generated code not sustainable? What future endeavors will the generated code hinder? How would people notice the hindrance?

Perhaps you can show examples of the kinds of changes they will likely make in the future, and demonstrate how the generated code interferes. Or maybe you can help them to notice the interference in their current work.

There are some limitations to this approach (helping them observe or predict ill effects). First, they may not agree about the kinds of future changes they'll make, or that the generated code will hinder in the ways you predict. Second, even if they agree, they may not see a better alternative. Do you have one?

Even with those limitations, I might try that approach first. Not so much to try to convince them, but more to elicit a reaction, which will give me more information about their beliefs and concerns.

More importantly: How come you don't like ass?

Dale

[mheusser]

This is one of the larger reasons that I am not a fan of the architect / implementer model.

If it were me, I would probably reframe the generated code as a proof of concept then go build "the real app" myself.  (I would probably quote fred brooks a lot, maybe leave copies of "plan to throw one away" around the office.)

Pushed to use the model (once I had a skunkworks, working, viable, "real app" competitor), I would reply "if team (X) likes the generated code, they can turn it into a product themselves, and our team can go build something else great and awesome for our company.  Would you like to do that?"

Good luck, man!

--heusser

[Andreas Leidig]

Hi Tim,

one more thought:
Focussing on the generated code may not be very helpful. Personally I hate generated code. I guess it is because nobody ever had the chance (or chuzpe) to show me that it has advantages.

Maybe you can challenge them:
Ask them to develop their code (which is the source for generation, not the generated code) test-driven. Let them convince you that their approach matches your expectations (test-coverage, flexibility, maintainability, refactorings). They might come with surprising ideas.

Changing your perspective from "The code is the truth" to: "The generated code is just compile output" may be really helpful. For me it helps when I'm confronted with really ass-like generated java code.

By the way: in what language are the model and the generated code?

Andreas

[Markus Gärtner]

You may want to use philosophy for that. Pointing to Harry Collins' Tacit and Explicit Knowlege and particularly the model of mimeomorphic vs. polimorphic actions might help them, that generated code solves only the mimeomorphic part of the problem, but not the polimorphic part.

On the other hand, you might not be able to argue logically with someone who reacts on an emotional level. At least "scientists" might be more open to fallacies regarding models if they were trained in polosophy and epistemology instead?

My two cents.

Best Markus

--
Dipl.-Inform. Markus Gärtner

it-agile GmbH
Paul-Stritter-Weg 5, D-22297 Hamburg

Geschäftsführer: Henning Wolf, Jens Coldewey
Handelsregister Hamburg, HRB: 92261
Umsatzsteuer-Identifikationsnummer: DE239483021

Fon: +49 40 88173-300
Fax: +49 40 88173-333
Mobile: +49 172 4297613
E-Mail: markus....@it-agile.de

http://www.it-agile.de

[Stephan Schwab]

They may respond to the challenge of test-driving their code by saying that the model is logic and therefore the code will have no defects, because it is just a transformation of the model.

I'm trying to see it from their perspective and think that they might very well respond like that.

What about talking about behavior of the application and what the future users want to do *through* the product? That might move the conversation from being confrontational to something more constructive. You mentioned that it's about creating a product. Personal plug: have a look at Activity-Centered Design (http://activitycentereddesign.com). It might help to show them that the model being implemented in code is just a tiny fraction of the product. I don't want to hijack this thread so I just refer to the same book, available at the URL I provided, for more details. Feel free to send me an email off the list.

Stephan

---
International Software Technology Consultant & Coach [German, English, Spanish]
Blog: http://blog.stephan-schwab.com Book: http://activitycentereddesign.com
Twitter: @snscaimito Profile: http://www.linkedin.com/in/stephanschwab

[Dale Emery]

Hi Stephan,

> They may respond to the challenge of test-driving their code by saying that the model is logic and therefore the code will have no defects, because it is just a transformation of the model.

A similar counter: The model /is/ the source code. The generated code is no more interesting than (say) JVM bytecode.

That's a reasonable perspective... as long as the system produced by the transformation is testable. By testable, I mean I can write tests that are:

- Fast

- Expressive -- each test clearly describes a meaningful responsibility of an identifiable agent.

- Diagnostic -- a test failure guides me quickly to the broken code.

- Maintainable -- I can quickly update each test when a relevant responsibility or implementation detail changes.

- Reliable -- I can reasonably rely on the test results to tell me something meaningful and true about the model code.

Dale

--
Dale Emery
Consultant to software teams and leaders
http://dhemery.com

[Erik G. H. Meade]

A common mistake with generated code, esp code running on a (J)VM, is to generate verbose code lacking abstractions. My generated code looks like the code written by other developers on the team, only better. No convention mistakes, no spelling mistakes, no implementations at different levels of abstraction and no missing tests, since those are generated as well. I find it fun and enjoyable, but then again I find TDD fun and enjoyable as well.

I haven't seen any tools that generate this kind of generated code. At best they allow you the hooks you need to introduce your abstractions (as code). Generating code is just another tool. Can they use the tool better build a sustainable product?

Are these right answers always and forever right or will they get more exact or change as the science improves? In which case you're probably talking about maintenance and in working with their own code will only drive that point home sooner or later.

I think the trigger you are looking for is getting a bigger picture in the product side of the house. Science still needs money.

[Michael Feathers]

The biggest question I have is whether they can be put into a continuous delivery situation. If they can, their focus will have to change. Users are the best teachers.

[Dale Emery]

Hi Erik,

> ... no missing tests, since those are generated as well.

Are the tests and the code generated from the same model? If so, why generate the tests?

[George Dinwiddie]

Dale, Tim,

On 6/20/12 6:53 PM, Dale Emery wrote:
> Hi Stephan,
>
>> They may respond to the challenge of test-driving their code by
>> saying that the model is logic and therefore the code will have no
>> defects, because it is just a transformation of the model.
>
> A similar counter: The model /is/ the source code. The generated
> code is no more interesting than (say) JVM bytecode.

That was going to be my response.

> That's a reasonable perspective... as long as the system produced by

> the transformation is testable. [snip]

It's a reasonable perspective as long as the intermediate code generated
by the model doesn't need to be edited. This means that all changes need
to be accomplished by editing the model and regenerating.

If you edit the intermediate code, it no longer reflects the model. It's
now a hybrid, and the model becomes meaningless.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Erik G. H. Meade]

Dale Emery <da...@dhemery.com> wrote:
> Hi Erik,
>
> > ... no missing tests, since those are generated as well.
>
> Are the tests and the code generated from the same model? If so, why generate the tests?
>
> Dale
>

Not always generated from the same model. When it is, it still documents the intended functionality and makes it easy to test with a lot of different data values. Having a test ready for you to just drop in a new test method is handy if people are complaining about how hard it is to write tests.

I generate them for most the same regular reasons I would write tests. Running the tests at different levels can illustrate gaps in value validations. They also still manage to catch those things that "shouldn't have mattered". In most cases code generation wasn't initially used, so I produce tests to match those people write by hand and are expected to be present to be a finished polished bit of code.

George D. mentions hybrids in another reply, there are techniques for dealing with those as well. Round-Trip is the buzz word often used to describe one technique.

[Matteo Vaccari]

On Wed, Jun 20, 2012 at 8:05 PM, Tim Ottinger <tott...@gmail.com> wrote:

We have a team who used to do research and pass their ideas on to
development after.
It's not my team, it's the team of a lady whose team I coached once upon a time.

Now they're expected to build a product.

They're big fans of building models (state charts) and letting the
code be generated.

The generated code is ass.

The question is where to find the psychological triggers to turn them
from "got the right answer" to "built a sustainable product."

Let the developers show the product to the users/customers?  If the customers like it, then you're worrying too much :)  If the customers' disappointment does not wake them up, what will?

Matteo
 

[Gerard Meszaros]

On 6/20/2012 1:27 PM, Dale Emery wrote:
> Hi Tim,
>
>> The generated code is ass.

> In what ways is the generated code not sustainable? What future endeavors will the generated code hinder? How would people notice the hindrance?

I haven't seen an answer to this question of why the generated code shouldn't be
used. Maybe I'm too old but I have no clue what code being "ass" implies ;-)
Does it not work? Or is it just not pretty. Does it have performance issues?
Does it have bugs?

While it might be more fun to build new code than to find ways to incorporate
the generated code, the latter might be the right thing to do if there is no
need to modify (or ideally, even look at) the generated code. I.e. the "compiler
output" view of things. Maybe the scientists' model *is* the right way to
represent the core logic of the application rather than translating it into a
much more verbose (I'm assuming) format such as Java. If so, could you not
encapsulate the generated code into a component and build the rest of the
application around it using a stable API that wouldn't change (much) when the
code is regenerated from a new version of the model.

The right answer isn't always to find a way to change their minds about the
model. Even though the question was phrased as "How do I change their minds?"
(Paraphrased heavily.)

Cheers,

Gerard

[Malcolm Anderson]

Tim

Generated code is often ugly, but as long as the model is under source control it shouldn't matter.
As someone else pointed out, the model is the code.

I'd push more for acceptance tests on the generated code. 
That way you you have an automated regression test suite in place.

I'm curious as to how long it takes for the code generation process. 

Also, what is the relationship between the code, the customer and the funding?

Malcolm Anderson

[Jon Kern]

sounds like the goal is to train them to be someone that they currently
aren't?

if so, i would inject that team with a kick-ass group that knows how to
develop product

mentor them and allow them to see how the sausage is made

jon

blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA

Tim Ottinger said the following on 6/20/12 2:05 PM:

[Jon Kern]

generated code is only as good as the originator is able to write code in the first place and abstract the domain of interest.

been there, done that, heard all of the arguments for and against presented on this thread, and probably 100x more.

generalizations on the topic are just about worthless

(not directed at you malcolm, i just jumped in at this point in the thread)

jon

blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA

Malcolm Anderson said the following on 6/21/12 2:04 PM:

[Malcolm Anderson]

None taken. Jon.

Could you restate your point?  I'm not understanding what your advice to the original poster is.

Malcolm Anderson

[Jon Kern]

my advice to the Tim (OP) is the prior response of mine...

this response is more for the tangent that the OP seemed to result in... one of debating generated code.

to that end, unless folks speak in specifics, the debate is a fairly ambiguous exercise.

generated code is neither ass nor panacea. generated code can be both of those, or neither.

i spent a lot of time with products like Together/C++ (code is the model, model is the code), and OptimalJ (MDA). Hence the "i've heard it all before" comment.

jon

blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA

Malcolm Anderson said the following on 6/21/12 11:23 PM:

[James Grenning]

Hey Tim

Others have already said this. If the model is the code, it does not matter. If the generated code needs to be modified, then generating code is not helping.

I think there is nothing wrong with generating code for state machines, when appropriate. Is it appropriate?

I'd consider these questions too:

Can the model be tested? Can it be test-driven? Is the cycle time fast? Does the code work? When stepping through it in a debugger is it clear enough what is happening?

The ass-ness of the generated code is not too important unless for some reason it does not meet performance needs, in which case it does not work. Generating is not helping then. I used to look at generated assembler, but generally feel no need to look at it now.

James

--------------------------------------------------------------------------------------------
James Grenning Author of TDD for Embedded C
ja...@renaissancesoftware.net http://pragprog.com/titles/jgade/
www.renaissancesoftware.net
www.renaissancesoftware.net/blog
www.twitter.com/jwgrenning