Alistair Cockburn

I think the 'Layered Architecture' section is all over the place.

There are a lot of terms thrown around with pretty loose definitions - in this article and others. I had to look up "layered architecture" to see what other people wrote about it, and it looks like an anti-pattern to me:

In a four-layered architecture, the layers are typically divided into: Presentation Application Domain Infrastructure These layers are arranged in a hierarchical order, where each layer provides services to the layer above it and uses services from the layer below it, and each layer is responsible for handling specific tasks and has limited communication with the other layers. [1] It looks like an anti-pattern to be because, as described, each layer depends on the one below it. It looks like how you'd define the "dependency non-inversion" principle. Domain depends on Infrastructure? A BankBalance is going to depend on MySQL? Even if you put the DB behind an interface, the direction of dependencies is still wrong: BankBalace->IDatabase.

Back to TFA:

> In the end, we gave it all up in favour of the good old dependency inversion principle.

OK. DIP is terrific.

> No port/adapter terms to learn

There is a big overlap between ports/adapters, hexagonal, and DIP:

Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases. [2] That is,…

I'm glad to hear this works for you. But I think the process emphasizes technical skills over what really matters when hiring: how the person works with the team and within the business.

Giving someone a toy project unrelated to the business tells you nothing about how they will perform in the real environment. Letting the candidate take the work home to work on it in isolation tells you nothing about how they will work with your team, or within the company.

In his study "People and methodologies in software development" Alistair Cockburn found that “People’s characteristics, which vary from person to person and even from moment to moment, form a first-order driver of the team’s behavior and results." (http://alistair.cockburn.us/People+and+methodologies+in+software+development). Other studies have come to similar conclusions.

In a technical job, actual skills and experience are necessary but not sufficient for success. Programmers fail in their jobs because they can't work with or fit in with the team, and the larger organization. Any competent programmer can learn a new language, framework, or technique like TDD in a week or two. But people who don't pay attention to the business environment and requirements, and can't work with their team, group, etc. will fail, often costing a lot of money.

Presumably you have weeded out the unqualified before offering to pay them to work for a few hours, but this seems like offering an unnecessary incentive to learn very little…

A couple of things spring to mind:

Naur's "programming as theory building" essay [1]. E.g.

> programming properly should be regarded as an activity by
> which the programmers form or achieve a certain kind of
> insight, a theory, of the matters at hand. This
> suggestion is in contrast to what appears to be a more
> common notion, that programming should be regarded as a
> production of a program and certain other texts

This suggests that it might not be a great idea to outsource
understanding. The entire essay is worth a read.

Yosefk also gave a fairly amusing characterisation of what it
is to work for a software company [2]:

> Basically the "knowledge worker's" contract is
> something like this:
>
> > We'll give you a precisely defined salary
> > and a benefits package. In return, we
> > request that you handle some problems that
> > we're told we're having. We hope that you'll
> > solve them well enough to prevent us from
> > having to know what they were in the first
> > place. Please help us maintain the feeling
> > that we own an asset similar to land or gold
> > or something. Please keep the realization
> > that we're more like the operator of a
> > flying circus than a landowner from
> > disturbing us. And certainly, never, ever
> > ask us what to do with any of the moving
> > pieces of this flying circus, because we
> > seriously have no idea.

[1] there's a copy here…

Great question!

I think we're slowly getting there. First we largely had verbs (procedures) that acted on data somehow. OO added a bit more on the noun side, so we could start to form simple sentences. IMHO much of the appeal of OO is due to this richer "sentence structure", with messages sent to objects.

Of course you could overdo it (see Yegge's Execution in the Kingdom of Nouns[1]), and the FP guys definitely think we overdid it and verbs were fine all along and who needs anything else. Verbs!

Higher Order Messaging[2] adds "adverbs", so we can say something about how those messages are to be delivered. It allows for some very expressive sentences, which you could also describe as crunching architectural patterns. See Sam Adam's great talk[3].

Polymorphic Identifiers[3][4][5] go back to the noun side, adding what you might describe as n noun-phrases, so you can have something more complex that again acts like a noun. Sort of.

Then there's Alistair Cockburn's work[6]

[1] https://steve-yegge.blogspot.de/2006/03/execution-in-kingdom-of-nouns.html

[2] https://en.wikipedia.org/wiki/Higher_order_message

[3] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf

[4] https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_11

[5] https://www.slideshare.net/MarcelWeiher/in-processrest

[6]…

Start with the "classics" like "mystical man month" (Brooks) for example, then get many of the books by Tom de Marco and possibly read Richard Gabriel's "Patterns of Software". The book about the "Chandler" project (forgot it's title) is also a particular good read. Those two in particular are interesting reads about why things fail.

Go on to reading the Toyota management style in itself, there's a couple of books about it, that's what many IT techiques are getting their ideas from.

It's mostly about finding your values so to speak and pinpoint what you really think makes up a good software development company - maybe your focus will be on organization, maybe on other things, so get an overview first.

These two articles are hopefully also an interesting nudge to think about many things:

http://www.computerworld.com/s/article/9137708/Opinion_The_unspoken_truth_about_managing_geeks

http://alistair.cockburn.us/Characterizing+people+as+non-linear%2c+first-order+components+in+software+development

O'Reilly has a very interesting book with analysis which practices actually work and why/how - sadly I also forget the title. There's for example a chapter about when and why pair programming works and when and why not.

Also, just watch carefully and learn to notice "good organization" - happens in surprising corners and niches and try to see WHY it's good.

I think there are a lot of loaded expectations on what it means to be an ORM. Maybe this is no-true-scotsmaning, but I distinguish between things providing convenient query builders from full ORMs.

Generally speaking, I'm happy with anything that handles marshalling / unmarshalling and can generate typesafe (when applicable) queries for me (so long as its happy to get out of the way on those handful of occasions that I'd like to use some handwritten SQL).

Things I've used in the past like this include

* Knex - http://knexjs.org/
* Slick - http://slick.lightbend.com/
* Opaleye - https://hackage.haskell.org/package/opaleye

Generally these don't call themselves ORMs though. The primary distinction I've found is that they don't conflate my domain model with my schema. They don't enforce a 1:1 correspondance to a table or a try to concoct some scheme of representing inheritance with multiple tables and they don't try to take on myriad other unrelated duties like validation, etc. They allow me to build my application in the hexagonal style ( http://alistair.cockburn.us/Hexagonal+architecture ) in an OO language.

Abstraction of SQL is not something I have a problem with, its trying to infect my domain model with persistence concerns, or even worse by trying to pull transaction handling out of the domain of the database.