Test-driven development (that's not what we meant)

[Anthony Green]

Steves talk at Scan Agile has been uploaded:

https://vimeo.com/83960706

[Evgeni Dzhelyov]

Can someone share a link to the slides, please ?

I've found one here: http://www.edinburgh.bcs.org/events/2012-13/131204.pdf

But maybe there is a better one with each slide on a separate page.

Thanks.

On Tue, Jan 14, 2014 at 1:31 PM, Anthony Green <anthony.ch...@gmail.com> wrote:

Steves talk at Scan Agile has been uploaded:

https://vimeo.com/83960706

--
 
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Björn Rasmusson]

Evgeni Dzhelyov wrote:

Can someone share a link to the slides, please ?

I've found one here: http://www.edinburgh.bcs.org/events/2012-13/131204.pdf

But maybe there is a better one with each slide on a separate page.

In the previous thread (https://groups.google.com/d/msg/growing-object-oriented-software/ma3WPD45Oek/B8ETNzLdUvUJ), this link to a one slide per page deck came up:
http://gotocon.com/dl/goto-berlin-2013/slides/SteveFreeman_TestDrivenDevelopmentThatsNotWhatWeMeant.pdf

Björn
 

Thanks.

On Tue, Jan 14, 2014 at 1:31 PM, Anthony Green <anthony.ch...@gmail.com> wrote:

Steves talk at Scan Agile has been uploaded:

https://vimeo.com/83960706

--
 
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriented-software+unsubscribe@googlegroups.com.

[Daniel Wellman]

At one point in the presentation, Steve did something that was very memorable for me.  He said something like (my paraphrasing): 

"If there's a continuum of design where one end is procedures [extends his left hand] and the other side is objects [extends his right hand], most people are somewhere around here [Steve puts his hand about a third of the way from the procedures end]."

Or if I can try with some plain text:

Procedures [=====*==========] Objects

  * Most people are here

So I'm curious - in your experiences, what aspects do you think people are missing?

Steve, I'm curious to hear what you intended when you say it -- and I'm also curious what the rest of this group has found?

Thanks!

Dan

[Alfredo Casado]

IMMO there are a lot o people writing procedural code with OO languages. As an example of this i see a lot times, in the JEE world, people are using frameworks like spring with hibernate/JPA, in this type of projects its very usual to have anaemic models, classes with properties and get&set methods, and services (aka transactions scripts) that manipulate this models objects (aka data structures). 

This services without state are like procedures, this models objects without behavior are really data structures, this is the definition of procedural programming: procedures that manipulates global data structures. This systems are not pure procedural because they use some legitimate objects in some places, but as a whole are near to the procedures "side" than to the objects "side".

In other technologies exists very, very similar problems. 

2014-01-26 Daniel Wellman <etl...@gmail.com>

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

[philip schwarz]

unlikely that anyone here needs these, but just in case:

• P of EAA: Transaction Script - Martin Fowler
  
• AnemicDomainModel - Martin Fowler
  
• P of EAA: Domain Model - Martin Fowler
  
• Why getter and setter methods are evil | JavaWorld
  

Unfortunately, Fowler's 'Domain Model' and 'Transaction Script' links are just summaries pointing to his great book, POEAA.

Philip 

[Matteo Vaccari]

On Sun, Jan 26, 2014 at 12:52 AM, Daniel Wellman <etl...@gmail.com> wrote:

At one point in the presentation, Steve did something that was very memorable for me.  He said something like (my paraphrasing): 

"If there's a continuum of design where one end is procedures [extends his left hand] and the other side is objects [extends his right hand], most people are somewhere around here [Steve puts his hand about a third of the way from the procedures end]."

Or if I can try with some plain text:

Procedures [=====*==========] Objects

  * Most people are here

So I'm curious - in your experiences, what aspects do you think people are missing?

Steve, I'm curious to hear what you intended when you say it -- and I'm also curious what the rest of this group has found?

Most people are OK with using objects to model things in the presentation layer.  Everyone agrees that a "button" object can encapsulate state and is preferable to having global variables that represent what the state of the button is.  

But, as one programmer told me once "objects for representing things of the business don't work" (his opinion, not mine).  There is a strong reluctance to model the problem domain with objects.  Or rather, most programmers immediately think "data schema", imagine an entity-relationship schema and then reverse-engineer the "object model" from that.   The resulting "object model" is anaemic, so then they write many service objects with names like FooManager, BarHandler or even Froobler, Warbler or Zorbler that have no state and contain procedures (actually what PoEE calls "transaction scripts").

This is what I have observed.

Ah yes, and then there are many complicated FoobarFactoryProviderBuilders that return globally accessible data sources.

Matteo

 

[philip schwarz]

Chris Richardson wrote a great book back in 2006: POJOs in Action.

Relevant sections:

1.2.1 Using an objet-oriented design.

2.2 Decision 1: organizing business logic.

2.2.1 Using a procedural design

2.2.2 Using an object-oriented design 

If I remember correctly, Chris covers those sections in the following 2011 video: Improving Applications Design with a Rich Domain Model http://parleys.com/play/514892250364bc17fc56bb63/chapter0/about

Philip

On Sunday, 26 January 2014 03:27:14 UTC, alfredo casado wrote:

[Steve Freeman]

Other people have covered most of what I meant. Part of it is about having more smaller types so that there's somewhere to localize behaviour.  It's also about taking the time to find the right name for concepts. Once in a while I get reminded just how strong the effects of renaming something AddressBook rather than ContactService are. The inappropriate functionality just doesn't fit any more. 

It took me a couple of years of smalltalk with some very good people to really understand why there was no switch statement. Most people don't get that opportunity. 

S. 

Sent from a device without a keyboard. Please excuse brevity, errors, and embarrassing autocorrections. 

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

[philip schwarz]

> in the JEE world, people are using frameworks like spring with hibernate/JPA, in this type of projects its very usual to have anaemic models

Here is how Chris Richardson describes (in POJOs in Action) the problem with J2EE (not to be confused with Java EE):

Why J2EE encourages developers to write procedural code

There are a couple of reasons why J2EE developers often write procedural-style

code rather than developing an object model. One reason is that the EJB specification

makes it seductively easy. Although the specification does not force you to

write this type of code, it lays down a path of least resistance that encourages stateless,

procedural code. When implementing new behavior, you don’t have to worry

about identifying classes and assigning responsibilities as you would if you were

designing a real object model. Instead, you can write a new session bean method

or add code to an existing one.

The second reason why J2EE developers write procedural-style code is that it is

encouraged by the EJB architecture, literature, and culture, which place great

emphasis on EJB components. EJB 2 components are not suitable for implementing

an object model. Session beans and message-driven beans are monolithic, heavyweight

classes that cannot be used to implement a fine-grained object model. Nor

can they represent business objects that are stored in a database. The best way to

use them in an application is to encapsulate an object model: the Session Façade and

Message Façade patterns.

EJB 2 entity beans, which are intended to represent business objects, have numerous

limitations that make it extremely difficult to use them to implement a persistent

object model. This is why I didn’t use them in our earlier example. EJB 2 entity

beans support some kinds of relationships, but not inheritance. Entity beans do not

support recursive calls or “loopback” calls, which are common in an object model

and occur when object A calls object B, which calls object A. We’ll discuss other limitations

of entity beans in a moment. Entity beans have so many limitations that it’s

amazing that developers have used them successfully. This is a fundamental problem

with the preferred J2EE architecture. Each framework creates a path of least

resistance for its use. It is possible to diverge from the path, but it goes against the

grain of the framework and takes a great deal of effort. The path of least resistance

in J2EE and EJB leads inexorably toward procedural code.

As a result, it has been difficult to do any true object-oriented development in

a J2EE application. Furthermore, this procedural design style is so ingrained in

the J2EE culture that it has even carried over into newer, non-EJB ways of developing

J2EE applications. Some developers still view persistent objects simply as a

means to get data in and out of the database and write procedural business logic.

They develop what Fowler calls an “anemic domain model” [Fowler Anemic]. Just

as anemic blood lacks vitality, anemic object models only superficially model the

problem and consist of classes that implement little or no behavior.

Philip

On Sunday, 26 January 2014 03:27:14 UTC, alfredo casado wrote:

[philip schwarz]

>EJB 2 entity beans...have numerous limitations that make it extremely difficult to use them to implement a persistent object model.

Of course Richardson did point out that EJB 3 (whose draft public spec came out while he was writing POJOs in action) was a step in the right direction, and noted that: "Entity beans support inheritance (finally!), making it possible to implement a true object model." 

Philip.

[philip schwarz]

>in the JEE world, people are using frameworks like spring with hibernate/JPA, in this type of projects its very usual to have anaemic models

The other day Michael Feathers, author of 'Working Effectively with Legacy Code' tweeted:

@mfeathers I have a copy of ‘Bitter EJB’ that I keep purely for historical interest. Future generations need to know.

Here is an example of how 'Bitter EJB' covered the EJB 2 problems around Inheritance and polymorphism that made it problematic to develop a rich domain model:

"As you know, inheritance is the capability of an object-oriented programming language

for one class to specialize or extend a base class. Polymorphism is the

capability of an object-oriented programming language for a subclass to override

a method’s behavior in one of its superclasses. Java supports both inheritance and

polymorphism. Many architectures require these capabilities as well. However, the 

entity bean specification does not properly support these concepts. Writing an

entity bean that extends a parent entity bean is possible. However, when executing

an entity bean finder method, the container returns only objects of the same class

as the entity bean’s object interface.

One common workaround to this problem is...This workaround presents

three major problems:...

Many other techniques and patterns emulate different parts of true polymorphism

and inheritance. ... Other patterns that rely on delegation

to emulate inheritance can support complex inheritance structures in databases,

but are even more unwieldy to code than our examples.

...

This begs the question: Why do we have to jump through all of these hoops at

all? Java doesn’t have these problems. In the words of Martin Fowler, a famous

modeler, "Entity beans don’t bring enough to the party to offset the drinks they

consume." No workarounds are nearly as full-featured or simple as the Java language’s

basic support.

The lack of true polymorphism is a bigger strike against entity beans than you

might guess if you’re just casting a passing glance. Polymorphism simplifies code,

but with EJB, architectures that lean heavily on polymorphism will become complex

and slow. Maintenance and future development of such systems are difficult

as well—the maintainers must be aware of the conventions and assumptions

decided upon when the system was first written. The crux of the problem is this:

You’ve now got to worry about translating from your component model to the

Java language! What’s next, Object-EJB mappers?"

Philip.

On Sunday, 26 January 2014 03:27:14 UTC, alfredo casado wrote:

[philip schwarz]

>in the JEE world, people are using frameworks like spring with hibernate/JPA, in this type of projects its very usual to have anaemic models

In "Real World Java EE Patterns-Rethinking Best Practices" Adam Bien reminds new generations of the bitterness of EJB in J2EE, and of the procedural code and anaemic domain models it

resulted in, and while he admits that the anaemic domain model is still prevalent, he says that there is no good reason for that. He says that with Java EE and JPA, the current best practice is rich domain models and the anaemic domain model is an anti-pattern, though he does qualify that with "at least in more ambitious projects" ;-) 

The 'Rethinking' part of his title comes from the fact that he revisits now outdated J2EE patterns in the light of Java EE.

One of the patterns he rethinks is the J2EE Core Patterns' Business Object: http://www.corej2eepatterns.com/Patterns2ndEd/BusinessObject.htm 

A couple of extracts from the 'Problem' section:

"The vast majority of Java EE applications are built in a procedural way without a reason. The business logic is decomposed into tasks and resources, which are mapped into Controls and anemic, persistent entities. Such a procedural approach works surprisingly well until type-specific behavior for domain objects must be realized." 

...

"All the shortcomings mentioned here are caused by the lack of object orientation in the persistence layer of most J2EE and Java EE applications."

A single opening extract from the 'Solution' section:

"The solution is surprisingly simple: Model your application with real objects and don't care about the persistence at the beginning. Real objects imply cohesive classes with encapsulated state, related behaviour, and inheritance. Just put business logic into the domain objects and use inheritance where appropriate. JPA turns out to be really flexible for mapping rich domain objects into relational tables. The more complex is the logic you have to realize, the less viable is the development of applications in a procedural way with anemic domain objects."

And finally, here is the 'Rethinking' section:

"The outdated J2EE CMP persistence didn't supported inheritance or polymorphic queries, so the anemic domain object approach was the only viable solution. The J2EE patterns were designed to mitigate such restrictions. Although alternative solutions, such as JDO or Hibernate, support inheritance, the situation did not improve. Due to the implementation of outdated patterns, most of the domain objects in production are still anemic -- without any reasonable explanation.

 

With the ubiquity of JPA, it's time to rethink the way complex logic is developed. Persistence is a cross-cutting concern and should not have any impact on design or, in particular, on the amount of logic residing in domain objects. Only the remaining cross-cutting and, often, procedural logic should be implemented in a Control. You should have a good reason to split the state and behaviour into separate layers.

Rich domain objects have become a best practice and the anemic domain model (http://www.martinfowler.com/bliki/AnemicDomainModel.html) is an anti-pattern, at least in more ambitious projects."

Philip

On Sunday, 26 January 2014 03:27:14 UTC, alfredo casado wrote:

[Anthony Green]

So I'm curious - in your experiences, what aspects do you think people are missing?

I can tell you what was missing for me:

Alan Kay's idea that the design of the system was expressed by the messages objects send each other.

How did come to realise I was missing something ?

By piecing together the fragments of a history of ideas I discovered from Smalltalker programmers: Steve Freeman, Sandy Metz, Kent Beck, David West, Rebecca Wirfs-Brook. (Mentions should go to Avdi Grimm, JB Rainsberger, Matt Wynne, and others for conversational aggregate)

At my age I'm very late to the party, but it does feel like a significant proportion of those now employed in the software field haven't undertaken that journey of discovery. My partner and I are both arts graduates and to me it seems we know the history of ideas in our respective fields far far better than my colleagues know theirs. 

[Steve Freeman]

This. I'm painfully aware of how much I missed on the journey.

S

Steve Freeman
http://www.higherorderlogic.com

Written on a phone, so please allow for typos and short content.

[philip schwarz]

>IMMO there are a lot o people writing procedural code with OO languages.... anaemic models, classes with properties and get&set methods...

Here are some extracts from Implementing DDD, in which Vaughn Vernon tells us why he thinks anaemia happens:

"So if an Anemic Domain Model is the sickly outcome of a poorly executed design effort, why do so many use it while thinking that their model is experiencing fine health? Certainly it does reflect a procedural programming mentality, but I don’t think that’s the primary reason. A good portion of our industry is made up of sample code followers, which isn’t bad as long as the samples are quality ones. Often, however, sample code is purposely focused on demonstrating some concept or application programming interface (API) feature in the simplest possible way, without concern for good design principles. Yet oversimplified sample code, which usually demonstrates with a lot of getters and setters, is copied every day without a second thought about design."

"There is another, older influence. The ancient history of Microsoft’s Visual Basic had much to do with where we are today...What I am talking about is the influence of properties and property sheets, both backed by property getters and setters that were made so popular by the original Visual Basic forms designer...The Java Bean standard was originally specified to assist in the creation of visual programming tools for Java...like Visual Basic’s. Soon almost every framework and library jumped on the JavaBean bandwagon. This included much of the Java SDK/JDK as well as libraries such as the popular Hibernate. Specific to our DDD concerns, Hibernate was introduced to persist domain models. The trend continued as the .NET platform reached us...."

"Most, if not all, of the Web frameworks also function solely on the JavaBean standard. If you want your Java objects to be able to populate your Web pages, the Java objects had better support the JavaBean specification. If you want your HTML forms to populate a Java object when submitted to the server side, your Java form object had better support the JavaBean specification. Just about every framework on the market today requires, and therefore promotes, the use of public properties on simple objects. Most developers can’t help but be influenced by all the anemic classes all over their enterprises. Admit it. You’ve been bitten by it, haven’t you? As a result, we have a situation that might be best labeled anemia everywhere."

Philip

On Sunday, 26 January 2014 03:27:14 UTC, alfredo casado wrote:

[philip schwarz]

>it does feel like a significant proportion of those now employed in the software field haven't undertaken that journey of discovery

Reminds me of the following answers David Parnas (of "On the Criteria To Be Used in Decomposing Systems into Modules" [1] fame) gave in a Q&A session on software engineering:

Q: What advice do you have for computer science/software engineering students?

A: Most students who are studying computer science really want to study software engineering but they don't have that choice. There are very few programs that are designed as engineering programs but specialize in software.

I would advise students to pay more attention to the fundamental ideas rather than the latest technology. The technology will be out-of-date before they graduate. Fundamental ideas never get out of date. However, what worries me about what I just said is that some people would think of Turing machines and Goedel's theorem as fundamentals. I think those things are fundamental but they are also nearly irrelevant. I think there are fundamental design principles, for example structured programming principles, the good ideas in "Object Oriented" programming, etc.

Q: What is the most often-overlooked risk in software engineering?

A: Incompetent programmers. There are estimates that the number of programmers needed in the U.S. exceeds 200,000. This is entirely misleading. It is not a quantity problem; we have a quality problem. One bad programmer can easily create two new jobs a year. Hiring more bad programmers will just increase our perceived need for them. If we had more good programmers, and could easily identify them, we would need fewer, not more.

Q: What is the most-repeated mistake in software engineering?

A: People tend to underestimate the difficulty of the task. Overconfidence explains most of the poor software that I see. Doing it right is hard work. Shortcuts lead you in the wrong direction and they often lead to disaster.

Q: What are the most exciting/promising software engineering ideas or techniques on the horizon?

A: I don't think that the most promising ideas are on the horizon. They are already here and have been here for years but are not being used properly. A few years ago, I met an experienced software development manager who had just uncovered a memo I wrote for his company in 1969. He told me, "If we were now doing what you told us then, we would be far ahead of where we are now." The biggest payoff will not come from new research but from putting old ideas into practice and teaching people how to apply them properly. There is much more research to do and we have much to learn, but the priority should be put on technology transfer and education.

[1] http://theknowledge.me.uk/mywiki/papers-and-blog-posts/On%20the%20Criteria%20To%20Be%20Used%20in%20Decomposing%20Systems%20into%20Modules.pdf

Philip

[Alfredo Casado]

Philip: thank you for the great quotes and research!. 

This bring back old memories about EJB's, one of the big problems with EJB its that the primary objective was to build a "distributed components" technology, similar to microsoft DCOM or (with important differences) CORBA. A lot of people use EJB to build a web application that executes in a single machine and accessing this EJB through local interfaces, i never understand why the people use a distributed components technology to build systems that are not really "distributed". The official blue prints from the now dead Sun at this times recommend use this EJB for business logic. The result of this is a lot of systems with "models" that are constrained by the decisions that the EJB designers take for building a distributed component system. If we think in a ports&adapters architecture is really clear that this EJB's are adapters not the model itself.

With JPA or others ORM's technologies (like active record) i see a similar problem but with the persistence, there are a lot of systems that have "models" that are designed with the constrains of a SQL database in mind. In fact its the same problem, build models that depends on the constraint of some concrete technology, this systems prevents developers to really use OO. 

2014-01-26 Steve Freeman <st...@m3p.co.uk>

--

---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

[Anthony Green]

On Sunday, 26 January 2014 15:46:44 UTC, Anthony Green wrote:

I can tell you what was missing for me:

Alan Kay's idea that the design of the system was expressed by the messages objects send each other.

I should be clear I'm talking about my understanding of GOOS/OOD here; I do expect to continue to learn about other stuff
:) 

 

At my age I'm very late to the party, but it does feel like a significant proportion of those now employed in the software field haven't undertaken that journey of discovery.

One thing that puzzles me is the number of prodigies software engineering seems to have, how do so many 20-somethings reach senior development positions in their first job out of college? Where are the experienced mentors?

[Tim Wood]

On 26 January 2014 15:46, Anthony Green <anthony.ch...@gmail.com> wrote:

So I'm curious - in your experiences, what aspects do you think people are missing?

I can tell you what was missing for me:

Alan Kay's idea that the design of the system was expressed by the messages objects send each other.

Something that influenced me strongly is the (concurrent) join patterns in JoCAML, where the state of the objects are encoded in the pending messages themselves. For example, this part of a vending machine (from http://en.wikipedia.org/wiki/JoCaml):

def coin(Nickel) & value(v) = value(v+5) & reply to coin

Which says something like: when there is a message on the channel "value" with the value v, and a message on the channel "coin" with the value "Nickel" then consume those messages and issue a message on the channel "value" with the value v+5.

So the state of the vending machine object is essentially the value in the message pending on the channel "value".

Here is how a cancel button is implemented:

or button(BCancel) & value(v) = refund(v) & value(0) & reply to button

(i.e. when the cancel button is pressed, and v is pending on "value", then "refund" v and issue 0 on "value").

[Malte Finsterwalder]

Reading all this is nice, but makes me wonder about functional programming.

Anyone here has any experience in functional programming?

I know about rich object oriented systems, but have no experience with functional systems.

So my understanding is very limited and naive.

So I was wondering, what is the equivalent of a "rich domain model" in a functional world? Isn't functional by definition a bunch of data structures without methods and then some functions that read those data structures and create new data structures? Is there any grouping of data structures and functions that act on them?

Does anyone have a good reference to books/articles about good functional design?

Greetings,

   Malte

[Matteo Vaccari]

The way I understand it, in the functional world you can model a domain with composable data and composable functions.  Peyton-Jones did work in the domain of financial options, described here:

http://research.microsoft.com/en-us/um/people/simonpj/Papers/financial-contracts/contracts-icfp.htm

I gave up on the paper, it's a bit dense for me, but the powerpoint slides are accessible.

The old book by Bird & Wadler  "Introduction to Functional Programming", is nice in that it shows how to solve a problem by decomposing it in small bits that can be solved separately.  

Matteo

--

 
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

[Steve Freeman]

Many of us find we've developed a functional/object layers approach. Objects provide services and have functional implementations. The game changers were linq, in the C# world, and Google collections in Java.

To start with, I would work through Real World Haskell and the OReilly Erlang book. Both will make you see things differently. Then come back and ask us again :)

S

[Angel Java Lopez]

I would add

Programming Erlang

Software for a Concurrent World

by Joe Armstrong

The Pragmatist Programmer

and

Clojure In Action

http://manning.com/rathore/ (I could wait for 2nd edition)

--

---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

[Matt Wynne]

Also: https://www.destroyallsoftware.com/talks/boundaries

Gary did a few videos on the DAS series where he did some practical exploration of this idea.

I think it was largely inspired by this blog post: http://michaelfeathers.typepad.com/michael_feathers_blog/2012/03/tell-above-and-ask-below-hybridizing-oo-and-functional-design.html by Mike Feathers.

cheers,

Matt

--

http://mattwynne.net

email: ma...@mattwynne.net

twitter: @mattwynne

skype: mattwynne
google hangouts: matt....@gmail.com

tel: +447974430184

[Nat Pryce]

Also it's common to have functions that return pipelines or graphs of objects and hide the construction and statefulness of the objects behind an API that makes it look like higher-order functions -- e.g. promises, Rx, function-reactive programming.

--Nat

--

---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
http://www.natpryce.com

[Anthony Green]

One thing that puzzles me is the number of prodigies software engineering seems to have, how do so many 20-somethings reach senior development positions in their first job out of college? Where are the experienced mentors?

Ross Pettit has provided an explanation for me:

http://www.rosspettit.com/2014/01/the-persistent-imbalance-between-supply.html 

[Steve Freeman]

Or, because the original career path was (is?) out of coding, so it was the last step before starting the "important" work.

S

[philip schwarz]

From point 2 of that post:

"Employers will pursue labor industrialization over tradecraft...On a person-by-person basis, it is faster, easier, and cheaper to hire, train, and staff industrial workers to work on a software development "factory floor" where they perform coding tasks in an assembly-line like way than it is to recruit, develop and mentor polyskilled software developers. New labor formation will be largely industrial in nature, not tradecraft."

Ony a couple of weeks ago Alan Kelly posted: Programmers without TDD will be unemployable by 2022 (a prediction)

Who will turn out to be right?

Today I was watching the second episode of Robert Martin's Advanced TDD video. At some point he says:

"a good TDD developer always approaches the problem from the outside in, testing the most degenerate things first, all the error conditions and boundary conditions, all the simple stuff around the periphery of the problem before he goes for the guts of the algorithm."

And the episode ends as follows:

"Tests can only prove a program wrong, they can never prove a program right, and if this is so, then how did we meet the desired goal of the program? The desired behaviour is achieved because there is a human being in the loop: you. You are smart. You know what the desired behaviour is. And so you gradually increase the generality of the code until that desired behaviour is achieved. And this takes patience, it takes creativity, it takes endurance, care and drive. In short, it takes a programmer, but not just any kind of programmer. It takes a craftsman to do this well."

How does that line up with "industrial workers...perform[ing] coding tasks in an assembly-line like way" ?

Philip