Mixing CRUD with your DDD

[Raif Harik]

This is new thread for a discussion that spun off of a different thread with the following topic "events that don't change state"    

[Raif Harik]

re: pdoh.  I have noticed that developers generally want to do what they've always done and they consider that to "be the right thing".  You are right it's a people problem, but it's not particular people it's people in general.  Atrophy is the way of the universe.  Constant vigilance is the price of good code.  If you have a small team of good guys, then you are lucky, but in my experience you will rarely if ever hire a guy who knows how to write good code.  Especially in .net, you'll hire smart people who want to be taught to write good code perhaps.  This is the inverse of another frustrating condition, and that is if you know how to right good code, you will rarely if ever find a company that does have a total shit code base.  Especially in .net. 

Anyway, more to the point, I think having guide lines and rules, perhaps infrastructure and such for when to use Crud in a  ddd app would be a minimum for doing it.

Lastly I would like to debate the relative "difficulty" of writing the day to day code of DDD.  I know modeling is quite difficult, but modeling a very simple concept, of the type you might op of crud on, is not terribly difficult.  The day to day code, is pretty simple to write.  Pass a dto, emit an event. write an event handler to project that dto to a read model. A lot of steps perhaps but all pretty simple ones.  

However, if we were to debate that, I would be jacking my own thread that i just started, so wtf.

r

[Raoul Duke]

I wonder if the "expense" (time and money) of modelling is having
access to the business / domain expert people, more than paying for
coders to implement the model. There's all the investment of figuring
out the domain language etc. etc. etc. before you get anywhere near
touching code. If it is an agile co-located mixed up team with all the
roles then that seems ideal and should lower the cost hopefully. And
become habit. I haven't managed to ever work in such an ideal
environment :-)

[Phil]

I can see your point.  I have seen devs (and been guilty of) getting into a new code base and essentially following the patterns/code already in place.  As a newcomer, often the dev wants to show productivity early. And is often expected to.

  If the code is good it generally stays pretty good. If it is moderate or bad it can get pretty bad.  My felling is that from a business standpoint...you can afford to have some bad code. In fact you are going to have some or you are going to go out of business(not absolute, but I hope you can relate).  With that said the team should know and accept where that "bad" code can exist.  It probably shouldn't be in your core domain code because that is what makes you money.

  My reasoning for saying that the DDD is expensive is not due to learning commands, events etc. As devs our core competency/domain is code, but when we become truly valuable is when we can quickly understand the business perspective of some other complex domain and bring that into software.  Doing that while correctly, while keeping a ubiquitous language is hard.  Even after the modeling.  It's also expensive because it takes time and experience for a dev to get to that point (IMO).

Phil

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Phil

[Kijana Woodard]

People are often shocked when I suggest something like, say, using scaffolding and EF for admin crud screens.

They are low value and I don't want to spend days getting something "pixel perfect" just to shove configuration data into the app once a quarter.

CRUD vs DDD is not reflective of the continuum of choices. "Not DDD" !== "hacky crap code".

There does not have to be "a single architecture" for the entire system. You can make different choices for different parts of the system.

If you can't, the DDD is nothing more than the next "best practice" death march like "n-tier development" before.

https://skillsmatter.com/skillscasts/1806-talk-from-udi-dahan

Skip to: 34m25s

[Ben Kloosterman]

On Wed, Nov 26, 2014 at 8:09 AM, Kijana Woodard <kijana....@gmail.com> wrote:

People are often shocked when I suggest something like, say, using scaffolding and EF for admin crud screens.

They are low value and I don't want to spend days getting something "pixel perfect" just to shove configuration data into the app once a quarter.

CRUD vs DDD is not reflective of the continuum of choices. "Not DDD" !== "hacky crap code".

Agree very strongly on both points .. a lot of devs don't WANT to get better , and their managers / companies do not want to be in a position where they cant rely on the cheap guy who has just done a 3 months course in India.   A lot of code does not hold enough value to use non CRUD methods.  Where there is not much complexity CRUD is quite often technically better as well with less and cleaner code, 

Ben

[João Bragança]

What is aggregate state exactly? An aggregate only *holds* enough state to enforce *future* invariants. But the state that it holds is not all of its state. Just because your aggregate ignores an event that it applies does not mean it's not part of the aggregate's state.

We're dealing with this in our domain right now. There's a part of the domain that really is just crud, things like title, description, notes and so on. The rules about these fields and even the fields themselves will vary per customer. Just let it pass through as a JObject or dynamic blob if you don't want the hard dependency on Newtonsoft.Json:

Draft: Command

  Guid Id

  OperationDto Important

  dynamic ZeroFucksGiven

Drafted: Event

  Guid Id

  AdditionalContextDto SomethingElse

  OperationDto Important

  dynamic ZeroFucksGiven

--

You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Sent from my regular computer

http://twitter.com/thefringeninja

http://www.thefringeninja.com/

[Kasey Speakman]

I would love to get into the practice of having different solutions per BC. However, so far I've ended up doing mostly small (team size) / lengthy projects, and using more than "one way" ends up adding administrative / knowledge complexity that are hard to justify at a conceptual level with a tiny team. When it comes down to it, the hidden complexity of trying to fit everything into one box might still be more work, but nobody sees it or it's hard to articulate and therefore ignored (i.e. hidden) until it's too late to change.

I suppose it takes both experience and trust between stake holders and devs to be able to develop something the "best way" (that is, devs don't waste time gold-plating things, and stake holders give devs the latitude to do proper solutions). But trust and experience take time and hardship to build. Who wants to sign up for that?

[Kijana Woodard]

The lite version is mixing approaches within one solution.

If the use cases are constructed vertically, it should be easy to separate later [if ever].

My assumption is that there's always a non ES data store at the ready, so doing crud with that isn't a big deal.

Since GES isn't suited for a variety of use cases [thankfully], I'd again assume there's another store available for crud.

I guess if you are doing GES  + Elastic Search maybe not. :-]

At any rate, maybe there's crud for some things, ES for others, event logging here, messages on queues there, some batch jobs [gasp!], some 3rd party sass integration [transactional email, stats/metrics/dashboard], etc, etc, etc. 

It would be pretty painful to go back to doing N-horizontal-tiers with a 3rd normal form db [+ stored procedures] for "everything".

It's "more things", but the team should spend more time communicating than writing code. Slowly add pieces as they become necessary. I admit that part is hard because mgmt wants the "architect" to "lay the foundation" for the entire 2 year project in the first six weeks.

[Kasey Speakman]

Yes, usually is another database aside from GES. However, when you start storing stuff in it not just for read models, it becomes another point of failure to keep up and recoverable rather than something disposable that you can (almost) not care about. Also for this project, one the ropes by which I am bound is the need to audit everything.

I agree with you about the standard tier solution. I couldn't make myself doing that again for everything either. It becomes too painful to maintain for all parties.

--
You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/X0UjLaoZt6Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dddcqrs+u...@googlegroups.com.

[Kijana Woodard]

"...rather than something disposable..."

Yup. I had this concern myself and my team mates help me get over it. I was getting a bit more "pure" than was justified by the overall situation. :-]

"...one the ropes by which I am bound is the need to audit everything."

Hmmm. Might still be able to do that with "blobs" assuming the blobs are immutable. But you'd certainly have to weigh pros and cons.

The "blobs" technique is useful for situations where information should eventually be forgotten [personally identifying data, etc].

[Jeff Harris]

Kijana,

Thanks for these responses, I feel like I'm getting a better handle on this.  How did you guys handle dealing with 2PC?  One of the voices in my head keeps telling me "if you just put it in GES, you don't need 2PC...".

[Kasey Speakman]

For me, the disposable read models aren't about being pure. It's about the surface area (both developer and admin) I'm leaving behind for a small team when my term runs out.

I have considered going purely Raven or SQL for the same reason and throwing an event store on top of that, but the amount of work to do that myself versus just using something off the shelf doesn't feel like a good trade off (especially when I have already written the GES integration). I did look at NES (and have experimented with JOES before), but I would basically have to rip out and adapt the storage part because my domain is too different from what is expected there. There's no right choice in the bunch, only trade-offs.

[Kijana Woodard]

"There's no right choice in the bunch, only trade-offs."

Agree.

Currently using NES. It's ok. I have my complaints, but meh.

[Kijana Woodard]

2PC for storing your blobs?

I figure it like this: if you store your blob/document/row and then fail to store your event, the client/app will see the failure. 

If the app resubmits, you may get a stranded blob. Does it matter? It will happen so infrequently, it won't be a storage issue. I suppose it depends if you're doing set queries over the blobs. In my case, they're just for kv access.

At the end of the day, I would look for a way to reduce technical friction and get on with building the app.

If "just put it in GES" gets you there, so be it.

My concern was the notion that every inch of an app MUST be constructed in the same way or it's "hacky crap code".

--

[Phil]

+1 

"My concern was the notion that every inch of an app MUST be constructed in the same way or it's "hacky crap code"."

I share that view as well. In fact, it seems to me that in a sizable app if everything is forced into being constructed using the same techniques/designs/architectures that it is more likely "hacky" crap code.

--

Phil

[Jeff Harris]

*smacks head*

Of course.

I just had the sudden realization that if I'm just *writing* data, and if I can live with stranded data, then it's perfectly fine to:

1.) Receive a message

2.) Write some new data somewhere + commit

3.) Send-a-message/publish-an-event that says where I wrote the data (its Id)

4.) If I really need to, do something later to help cleanup orphaned stuff previously written...(e.g. denormalizer to create a view of all the Ids I've written, chasing-reader to add some metadata to the data I wrote that says it's now associated with an event, etc) 

I think my problem is my newbie-ness, and my lack of a repertoire of solutions to problems that are not-quite DDD and also work well in the CQRS/ES world. 

This group is a great resource...my thanks to everyone who participates.

[Ben Kloosterman]

On Thu, Nov 27, 2014 at 1:55 AM, Kasey Speakman <ka...@cornerspeed.com> wrote:

I would love to get into the practice of having different solutions per BC. However, so far I've ended up doing mostly small (team size) / lengthy projects, and using more than "one way" ends up adding administrative / knowledge complexity that are hard to justify at a conceptual level with a tiny team. When it comes down to it, the hidden complexity of trying to fit everything into one box might still be more work, but nobody sees it or it's hard to articulate and therefore ignored (i.e. hidden) until it's too late to change.

Everyone knows CRUD , and trying to push CRUD into DDD is a far worse problem  because it lets the CRUD mentality in - some people will NEVER come across to CQRS  you can fire them or find a Crud job in the project for them . There is no hidden complexity after all the read model IS the query side.

Trying to ram complicated frameworks down peoples throats  is much worse then a simple horses for course approach. Thats why i like Gregs Simple CQRS and not fancy CQRS frameworks .

Also when working with larger teams and bigger projects I find that the skill set tends to drops. 

With a light version you can make say 30% CQRS or 70% as suits the type project  but more importantly to suit the current skills of your team and the market place.

 

I suppose it takes both experience and trust between stake holders and devs to be able to develop something the "best way" (that is, devs don't waste time gold-plating things, and stake holders give devs the latitude to do proper solutions). But trust and experience take time and hardship to build. Who wants to sign up for that?

Most PM , stake holders need to fall flat on their faces once or twice most people run or have experience managing simple CRUD based app projects ( this goes for developers as well)  . They apply the same rules to complex systems.  I had it again this week , im working in a project where we are manufacturing explosives at 800 remote sites on vehicles and then deliver it into holes  and then report what was delivered via QA ( there are about 6 applications including a web site)  . Management spent 9M mostly outsourcing it to India - the code was so poor we threw 90% away , we got some wins now but i got asked again why does it take so long a screen in SAP only takes a few weeks ...

Its not an argument you can win , commercially  you will loose to a CRUD quote from someone who has not done such a project . And i have seen many cases internally as well developers submitting expensive solutions and the organization then went outside. 

Ben

[Ben Kloosterman]

On Thu, Nov 27, 2014 at 8:10 AM, Phil <pdo...@gmail.com> wrote:

+1 

"My concern was the notion that every inch of an app MUST be constructed in the same way or it's "hacky crap code"."

I share that view as well. In fact, it seems to me that in a sizable app if everything is forced into being constructed using the same techniques/designs/architectures that it is more likely "hacky" crap code.

+1 that should be a rule.. 

To do that you need very heavy framework and strong control over developers -which do not scale to large projects. 

Ben 

[Kasey Speakman]

My concern was the notion that every inch of an app MUST be constructed in the same way or it's "hacky crap code".

Yes, I agree with this as well. Even though I'll be event sourcing CRUD for auditing purposes, I'm certainly not going to waste resource trying to go full domain on that. The "one way" I'm talking about is more about sending commands to change CRUD rather than writing to directly to a separate CRUD database, which I would also have to make highly available, add to the DR plan, and also develop another code path to save data into the system. Again, I need to audit the CRUD data as well though. And even so, if I had more resources, the separate CRUD database would probably be better.

[Kyle Cordes]

On Monday, December 1, 2014 at 8:50 AM, Kasey Speakman wrote:
> Yes, I agree with this as well. Even though I'll be event sourcing CRUD for auditing purposes, I'm certainly not going to waste resource trying to go full domain on that. The "one way" I'm talking about is more about sending commands to change CRUD rather than writing to directly to a separate CRUD database, which I would also have to make highly available, add to the DR plan, and also develop another code path to save data into the system. Again, I need to audit the CRUD data as well though. And even so, if I had more resources, the separate CRUD database would probably be better.
>

I believe this is a good way to do it. The alternative of having two different audit trail mechanisms, which need to be merged to present a full audit trail report, seems worse.


--
Kyle Cordes
http://kylecordes.com

[Ben Kloosterman]

. Also for this project, one the ropes by which I am bound is the need to audit everything.

You never audit "everything" ..  It is one statement i hear very often and is equivalent to i "want everything to be fast ".

I always drill down further and i have seen many CRUD systems qualify for "everything" with 50% of the tables having a lastChanged User and changetime and a single table which has a transactional style  .  ( Note these transactional tables are often the bottle neck and benefit a lot from CQRS) 

> Yes, I agree with this as well. Even though I'll be event sourcing CRUD for auditing purposes, I'm certainly not going to waste resource trying to go full domain on that. The "one way" I'm talking about is more about sending commands to change CRUD rather than writing to directly to a separate CRUD database, which I would also have to make highly available, add to the DR plan, and also develop another code path to save data into the system. Again, I need to audit the CRUD data as well though. And even so, if I had more resources, the separate CRUD database would probably be better.
>

Its good for command handlers to run CRUD. Though its a good idea for some front end service to create such commands so people writing that code are not that exposed to it.

re nTier 

I stored procedures ( or raw sql)  cause massive issues due to deployment / flexibility / maintenance costs but products like Entity Framework code first  and xml fields can make CRUD pretty light and significantly reduce the maintenance costs. A 5 or 6 class framework is all you really need.. managing an extra DB is not really a big issue unless you are remote or very small nearly all organization do  large amounts of db maintenance and the procedures / policies do have value .  Introducing something unusual is in fact far more time consuming / disruptive. 

Ben

[Raif Harik]

@Ben, 

"Its good for command handlers to run CRUD. Though its a good idea for some front end service to create such commands so people writing that code are not that exposed to it."

are you suggesting that from client side to command handler everything looks the same crud or ddd but then in the command handler you "pull a fast one" and persist via crud?

I like this approach, if one HAS to do crud, because it keeps most of the process the same, switching design pattern at the last minute.  Still the risk of saying, oh screw it i'll just send this via nhibernate, but you have to trust your devs at some point.

r

[Kijana Woodard]

"...but you have to trust your devs at some point."

They either have a good point and made a valuable trade off or they didn't [according to you]. If they consistently make "bad choices", they shouldn't be on the team. If the rest of the team consistently disagrees that the choices are bad, you shouldn't be on the team. :-]

--

[Jeff Harris]

I'm a bit late to some of this, but having just watched Greg's "Assert.That(We.Understand)" talk, it makes total sense that we normally want to test:

Given a series of events has occurred, When a command is given to a handler, this series of events occurs.

I think it logically follows that the real power of the DDD/CQRS is actually *events*

The "Aggregates/Process-managers/sagas/crud-services/whatever-you-want-to-do" should be the simplest possible way of getting the correct events spit out. In some cases this is Aggregates, but in other cases, it's simpler than that -- just worry about spitting out the events the business cares about as efficiently as you can.

So basically: whether or not an event changes the state of an aggregate or are spit off of a CRUD service that only matters internally? And that's a decision you'd make based on how complex the logic is and how much the business cares about it?  

Maybe an effective way of preventing "hacky-crap-code" would be to have a few different standard ways of getting events written depending on the needs of your business -- but having everyone agree on the events you need?

I think I'm coming around to this way of thinking.

[Brian Mavity]

@Jeff,

That's the major breakthrough that I had within the past 6 months or so. At some point, someone mentioned the idea of "CRUD events" which is what actually allowed the shift to take place.

As an aside, I'm really enjoying this conversation.

--

[Jeff Harris]

Yeah, I think I'm seeing that "events as a contract" is the way of avoiding hacky-crap code.

As long as you get the events correct, you can go as far as you want to when it comes to enforcing consistent solutions -- but it really doesn't even matter what language each BC is implemented in, let alone what design patterns are used.  They can all be replaced.

[Raoul Duke]

hah! so how do you get the events correct? and how do you fix all the
various and sundry things that emit/consume them when you realize you
have to revamp? :-)

[Kijana Woodard]

You have to be thoughtful and careful [a major part of the cost of ddd]. But ultimately, you'll probably make mistakes anyway,.

No matter. Create new models that compensate for the mistakes. You can even create new event streams if you're really disgusted by your errors. ;-]

[Jeff Harris]

@Kijana: exactly

@raould: yes, but defining interfaces between BCs always requires care.  In the case of a CRUD BC, your events are probably just C, R, U, and D?

One thing I noticed as I was having trouble determining my Aggregates was that if I focused on the commands and events, the internal structure of the BC was becoming clear.  

For example, if I see that the business really does think of the events as "CRUD", then it probably makes sense to implement the BC with CRUD.

[Raif Harik]

@kijana in reply to me :) the problem with trusting your team is that often they are working on different parts of the system and you don't have direct overview of what they are doing.  This may be a silo smell, but if they are working on different parts of the system, you'd have to get ramped up on everything they are doing to understand the decisions they are making, at which point I may as well just build it myself.  

@jeff and @brian at first blush I think I agree.  However, at second blush, if there is such a thing, I ask, if you are creating a command and creating a command handler, and emiting events, then what's the work difference between calling nhibernate and all the mapping and so on vs creating an aggregate built up by the events receiving the command and turning that into an event?  I guess there may be one step less in that you are writing to readstore ( via nh ) and you don't need to create a handler specifically for writing to the readstore.  

I think this is where some clarification of what crud vs AR means.  If we are reading and writing from the controller action, then yes that's much less work.  albeit possibly crap.  If you are doing all the same things ( cmd, cmd handler, read, write, emit event, handle events) then the only difference is how you read and write and that, in my opinion is definitely not worth switching infrastructure for.

@kijana was looking for you in jabber yesterday.  I made a bit of a compromising break through yesterday.  I'm working with oauth to post tweets, linkedins, and facebook crap.  The actual command is requires of course one or more http calls, which you would not want to do inside an aggregate.  So I realized I could have a command handler receive the command and either call an app service or do the work it's self, and make the posts etc, then post events that "document" the results and can be used to update read models etc.  So in this case the app service is acting sort of like an aggregate by doing work and emiting events.  I'm not really sure how or if this is relevant to you but I seem to recall some discussion with you about something similar.

Anyway, good stuff, I like this discussion too.

r

[Jeff Harris]

Raif, I encountered a similar situation with command handlers performing work, and I think I've recently had a breakthrough -- 

So what I *was* doing, was designing by defining BCs, then looking for ARs -- and then thinking about what Events I'd need to emit to change the states of the ARs.

What I've realized is that this approach pushes me towards an over-engineered solution, or at the very least thinking through a bunch of different ways to structure aggregates.

I think the breakthrough for me is that if I start with BCs, then go to Events, and the Commands that will lead to these events, it starts to become more obvious what needs to happen in the middle -- do I need an AR here? Is anything actually changing state? Are all state changes CRUD?

To your point -- it's *possible* that it might make sense to use DDD principles for infrastructure reasons -- but with my new way of looking at my BCs I can start to feel some pain when I'm taking things too far.

I can also better focus on events with business meaning, and see events coalesce around common "nouns" that can give clues to what ARs might be needed.

[Ben Kloosterman]

Yes  i am why should the front end care about the implementation. 

Technically the EventHanlder model is not what defines CRUD vs DDD in fact Xml messages with web calls/ Services are translated to "commands" ( ie the xml message on the wire)  and converted back to functions calls by most frameworks.

The only issue with this is you may loose the strength / pollute the "business language"  commonality with DDD commands. 

re trusting devs ..  You specify some BC as DDD and some us CRUD ..  DDD skilled devs work on DDD , CRUD devs work on CRUD ones. 

Designing frameworks and systems to handle bad devs  is IMHO the penultimate form of our  art  because there will be many in any large project  You cant have strong / heavy frameworks because  they just wont use it / work around it and if you kick up a stink there be a posse  against it  , so I use light framework  that are very easy to use and carefully pick the critical points.  

You have to be flexible . The last project i suggested event sourcing for 1 part  ( Its very distributed and lots of concurrency issues) but 5 senior guys didnt want a bar of it because it wasnt standard sql and they had never used it. It was my call but not worth driving against every one else.  

Its always interesting how people who have no idea about a technology will go against it if requested/ forced/ order in a group situation but 1:1 the better ones will try it and learn and become converts.   

Ben

--

[Ben Kloosterman]

On Sat, Dec 6, 2014 at 6:44 AM, Jeff Harris <jhar...@gmail.com> wrote:

Yeah, I think I'm seeing that "events as a contract" is the way of avoiding hacky-crap code.

Contracts dont avoid crappy code eg SOA services - dont see how events change that . They do contain / limit its impact and make it easier to replaceable  parts  

As long as you get the events correct, you can go as far as you want to when it comes to enforcing consistent solutions -- but it really doesn't even matter what language each BC is implemented in, let alone what design patterns are used.  They can all be replaced.

Thats the CRUD mantra write it cheaper and quicker and replace it  when you got it wrong or requirements change !  Which is why it works very well for small screen apps. and small services with little BL. .

Regards, 

Ben. 

 

[Kijana Woodard]

"the problem with trusting your team is that often they are working on different parts of the system and you don't have direct overview of what they are doing.  This may be a silo smell, but if they are working on different parts of the system, you'd have to get ramped up on everything they are doing to understand the decisions they are making, at which point I may as well just build it myself. "

Ah our old friend legibility is back to haunt us once again. 

Since you "you don't have direct overview of what they are doing", you can't be sure what their needs are and therefore shouldn't impose artificial constraints on their code. The dilemma is you're "in charge", but can't possibly "know" enough to make informed, detailed decisions. We're on our way to PHB territory. The only "fix" I'm aware of is to guide and trust.

http://www.ribbonfarm.com/2010/07/26/a-big-little-idea-called-legibility/

--

[Raif Harik]

@kijana, re http://www.ribbonfarm.com/2010/07/26/a-big-little-idea-called-legibility/ nice read.  I disagree with his assessment that legibility led to the fall of the roman empire ( with out thinking too hard about it, my assessment is that great empires require great leaders that far too infrequently land on the thrown.  This is repeated in just about every great empire.  The faster the rise, due to a particularly great leader, the faster the fall through the mediocrity of subsequent ones.  See Ghengis Kahn ).

None the less, he's right on most scores.  That said, this is a critique of the human condition as illustrated by the fMRI example.  It does not proscribe a winning solution, just that we will all inevitably fail.  Which is true. And depressing.  

r

[Kijana Woodard]

"Which is true. And depressing."

:-] :-] :-] :-] :-] 

I guess it's liberating in a way as well.

All that to say, if mediocrity at the top is common, designing a system which requires quality at the top is bad idea. A better approach might be to enable distributed control. Even if it's mediocre, one failure doesn't take down the entire system.

[Raif Harik]

It's interesting, back when I was a cabinetmaker/entrepreneur there was this book called the e-myth.  back before e meant e.  One of the major hypotheses was that one should design systems that require the lowest possible skill level to operate.  That having "rock star" employees was a great liability on account a them getting hit by a bus and so on.  When I entered the software industry, I found that rockstars were required.  It seemed impossible to build quality software with out the highest skill set available.  Still does.  None the less, according to legibility theory, what with mediocrity rising to the top, one can only assume that this process is doomed to fail.  Which it does.  All the time.  Perhaps revisiting the e-myth is in order.

r

[Kijana Woodard]

Since you're the OP, I guess we're not OT. ;-]

Perhaps the problem is "trying to scale". If scaling means having a big org, then having enough quality people is going to be a problem.

If scaling means, in our case, building great software, then "more people" is often counter productive [Mythical Man Month]. So then we start to ask why we even need this other team that "might do the wrong thing". Generally this results from [mediocre] managers wanting to have multiple initiatives "in progress". It's an extension of the illusion that multitasking === more productivity. 

My experience is that "things get done" with smaller teams learning as they go and using that learning to build efficiency into the construction process [conventions]. But that's usually a bit too much "trust" for [mediocre] managers. So we have bodies thrown at problems and then assign an "architect" to be "responsible" for the technology. 

There's only one possible outcome - top down decisions made at the point of least understanding. [paraphrased from Dan North]

[Raif Harik]

Yes this is the plague of humanity.  quality doesn't scale.

r

[Kasey Speakman]

Thanks for this link Kijana! Also don't miss this post about management science, which I also found thoroughly enjoyable.

You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/X0UjLaoZt6Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dddcqrs+u...@googlegroups.com.

[Kasey Speakman]

http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-the-office-according-to-the-office/

[Kijana Woodard]

I recommend that link regularly. ;-]

The entire blog is worth reading. The articles are very dense though; not much light reading. Fwiw, also one of the few places on the internet where the comments are worth reading. Lots of smart people chiming in there.

[Kasey Speakman]

Well since I recommended this, after finishing it, I will have to un-recommend the last 2 or 3 posts in the series. It started as a hilarious look at corporate management through a heavily cynical lens, but the author gradually weaves the narrative into a self-justification of his own position as a "Sociopath". Then the conclusion is predictably self-aggrandizing and useless. Also, after pointing out the delusions of the other two, he misses (probably necessarily) the "Sociopath's" delusion, which is one of being a god. This fiction is all but spelled out in the last two posts.

Needless to say, I was a bit disappointed that he didn't stick with a more technical analysis. However, the first few posts are still really funny and a frighteningly accurate model of some real companies.

[Raif Harik]

@kasey, Wow, scathing review.  I'm torn, on the one hand I want to read it to see what you are talking about but on the other hand I don't have time to read crap which is what you say it is.  I guess I'll check jira and see if I have time. :)

R

[Kijana Woodard]

Read the first one for sure. I will discuss the other two, but not here. LOLOLOL.

[Kasey Speakman]

Oh, it is hilarious and the observations are very interesting. But Kijana was right, it is not light reading.

[Kasey Speakman]

Yeah, sorry, my C personality likes to point out the inequities, which is a bit off-topic.