It's All About The Business

[Ian Taite]

Forgive me for asking, but I fear I may be mentally ill :-)

I've spent many years working on web based IT systems, and I think in every case, there have been serious issues with the (a) the way code is organised, (b) the responsibilities assigned and (c) coupling. I have to say, somewhat sheepishly, that I've even left projects because I was sick of the maintenance issues a/b/c caused.

Since about 2008, a trend I have observed is that presenters at user groups and conferences use completely trivial scenarios to illustrate "the way we should be doing things". There is also heavy emphasis on the likes of MVC, or Entity Framework, or other next-big-thing technologies. To me, these are all peripheral. (I admit they are good fodder for conferences etc, they're just are a means to an end).

No business gives a crap about MVC, NHibernate, NoSql, Angular.js or insert-your-pet-js-lib-here etc. For years now, all of that has been distracting developers from what really matters.

What businesses care about is having software that models entities AND processes that matter to the business, that can change and evolve over time (be maintained) and stay robust.

Why isn't there more focus on that?

Anyway, what I find when I look at existing code across many businesses is this:

1. There is often significant use of static methods in business model objects which effectively dead-end any attempts to cover the code with automated tests.

2. Static methods in business model objects call static methods in other business model objects willy nilly to achieve their ends.

3. Minimum dependency injection. Often token use of a DI container because it's the done thing without concern for appropriate container use.

4. Sometimes I find all the logic moved from business model objects (all properties and no methods), and heaps of "services" or "managers" containing methods and no state.

It seems to me what's needed are some reference implementations that make it clear where different kinds of behavior live, in a specific context like an e-commerce site; something sufficiently complex yet familiar.

I'm not looking for the one-architecture-to-rule-them-all, but it would be very valuable to contrast the design decisions that went into different implementations based on the same problem domain.

I also have another holy grail:

How to design systems based on simple objects and methods so that I can focus on the interactions and dependencies without regard to caching, dependency injection (tooling) and persistence and the heap of other concerns that get in the way of understanding what the system does.

I want to put what the system models and what the system does at the center and push or defer all these other concerns until I absolutely need them.

I want to be able to focus on test-first or specification-first, where the production code is almost a side-effect of defining tests and/or specs, and where the tests don't necessarily have to deal with faking web contexts and other infrastructural concerns.

I don't want to be starting implementation by adding code to a controller action. In fact I don't really want to test controllers (and deal with all the context mocking that entails).

Concrete reference implementations for this holy grail?

Are there any that are publicly available that deal with read/write persistence?

Are there any available via courses?

Are there any available that show how different objects in the system should interact? e.g. how one collaborator is used via the "caller".

I must be one of thousands of developers who have come to this realization.

BTW I've been watching bob's videos and I'm up to 25 or thereabouts. I find the occasional mention of Interactors tantalizing and feel this is a step in the right direction but I would like a larger example that covers multiple interactors with read and write scenarios.

Most of the work I do is brown-field. I used to think any code base could be rescued and made clean, but now I think that some code bases are beyond economic repair.

Regards, Ian.

[Frédéric Bouquet]

Hi,

I'm somewhat happy to read what you say as I'm not feeling alone with
this feeling :)

It's been several weeks I've tryed following the clean
code/architecture path on personal (and when I was allowed to do so,
professional) projects but I often feel without help when I'm facing
design problems. That's part of my last message on model interactions
(but as I see no answer yet, I think I may not have been very clear in
my questions).

While looking around the web, it's hard to find some example but hard
to find some nice things. I have in a part of my hard disc fitnesse
source code but it does not help so often. I found this tweet
https://twitter.com/unclebobmartin/status/286167065671372800 and this
post https://www.paluch.biz/blog/83-clean-architecture-code-examples-for-an-onion-architecture.html
which may be a good starting point.

When I'm looking at what I've found from uncle bob, it seems his
vision is a world without framework, or use them only when you can't
do anything else... I may be wrong as it's only what I see from the
state of my research :)

I'm open to examples and real world examples too

> --
> The only way to go fast is to go well.
> ---
> You received this message because you are subscribed to the Google Groups
> "Clean Code Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clean-code-discu...@googlegroups.com.
> To post to this group, send email to clean-code...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clean-code-discussion.



--
Frédéric Bouquet
Twitter/Github : bouquetf
http://www.espacedefouille.org/

[Jakob Holderbaum]

Hey Guys,

really nice to read those two E-Mails since I felt being haunted by the
same issues. Especially the hypes around tools and libraries on
conferences and/or github are 90% of the time awfully far fetched and
lacking actual relevance in a professional or legacy environment.

> When I'm looking at what I've found from uncle bob, it seems his
> vision is a world without framework, or use them only when you can't
> do anything else... I may be wrong as it's only what I see from the
> state of my research :)

I found this to be true in my own thoughts before this project started
and actually confirmed now. Thanks for this insight!

The issues with the lack of examples and such was also a problem for me.
Last year I was assigned to the technical advising and implementation of
a green field project with a small team at a company. We struggled a lot
with management and could finally get the time to do it all from
scratch, focusing on Books like "Implementing DDD" from Evans and the
"Clean Code" from Uncle Bob.

We constructed a really clean code base in about 1 year that consists of
a dozen of separated components, all running as standalone (hexagonal or
layered or clean, name it how you want) applications that are
dynamically wired up by main on boot time.

The application is a ruby platform, it has to be the base for a lot of
large and slightly customized applications in the next 5 to 10 years.
Delivery is implemented with rails (which is just another component).

Since all of this is closed source, I can't really give any information. :(

But I am planning (and I'll start soon) to build a new application from
scratch that contains a lot of problems we faced during the project.

I started a blog to share some of the experiences I made with this
project (http://jakob.io/).

The project will be open source and I'd be more that happy to get
discussions about it here or on other platforms, reddit for example.

Kick-Off will be in one to two months, currently I am very engaged in
some other issues. That justifies also the current pause on the blog.

My vision with this project is to share as much information as possible
about planning and development from the earliest moment on. On the one
hand to provide a guide for others and on the other hand to gather as
much critique and feedback as possible.

I will definitely let this list now as soon as I kicked this thing off.

Any thoughts about this idea?

Cheers

Jakob Holderbaum, M.Sc.
Systems Engineer

0176 637 297 71
http://jakob.io/
http://jakob.io/mentoring/
h...@jakob.io
@hldrbm

[Sebastian Gozin]

Once again I'll echo the sentiment of others replying here that yes I have had a similar experience and frustration.

For the most part I have been unable to convince external teams I was a part of as a consultant to try a clean code approach.
Everybody appears to have a pet peeve which is fine by me but not when it has to exist at the expense of clean code.
For example, a colleague wanted to build a simple JPA based data structure without complicated mappers but he could not live with my constraint that the JPA annotations could not live in the core application library.
I found this frustrating because I felt no desire to stifle his enthusiasm and I felt I provided a reasonable compromise but alas.

Projects for my own business do following a clean code approach. Everybody feels pretty happy about working on it as well.
Things work pretty well and sure we made some mistakes here and there but I feel like we are not getting stuck the way other projects sometimes do.

As for an example of how to approach such a project.
I think the cleancoders.com case studies show it pretty well in the sense that I start with a FitNesse test/fixture instead of a web controller and write the basic client interactions.
Then I drop down to simple TDD for the business components and an in memory persistence strategy.
I wire those components into the FitNesse test to make it pass and then proceed with integration tests for a real persistence and web transport strategy.

For database strategies that works well but I've found some duplication between my FitNesse fixtures and web controllers so lately I've been practicing pushing as much as possible out of there into the core application.

[Caio Fernando Bertoldi Paes de Andrade]

Here I am also to corroborate this issue. I reckon this is all due to the deep lack of professionalism in our field.

Business pushes programmers who bow and rush. Rushing means coding a lot and thinking as little as possible. Thinking little means delegating hard design decisions to someone else, and in most cases this someone else is the creator of the tool of choice (framework or library). So the tools’s creators make all the hard decisions with no project knowledge, programmers think little and accept all those decisions, making projects shaped by tools. Programmers then see the tools shaping the project and think of the tools as most important, instead of the design decisions behind them.

Programmers hold on to tools as labels to try to express their experience (good or bad) with the design decisions behind them, and the Tool War starts. Frameworks against frameworks, just like the good old languages against languages, everyone trying to find the holy grail that will make all the hard design decisions for them with no drawbacks and save them from the big muddy old stinky codebase.

All this is very unfortunate, but I think it has already started to change. I was one of those programmers not too long ago, and I have changed. I tried for some time to argue with a lot of people right away about design principles and architecture, but we just never spoke the same language, they are always too biased by the tools and can’t see past them. The way my thinking changed was first through bad code pain, then clean code instruction, then test practice, then architecture enlightenment, so that’s the path I’m guiding my clients through. I don’t deeply discuss architecture or tools with them before any of the former items, I learnt to respect their learning curve, just like Uncle Bob did with us. ;-)

About publishing some code samples, I keep my opinion that although it’s a nice initiative, it won’t solve the problem. The code is less important than the process of coding. The process of coding is less important than the craftsmanship mindset. And the best way to spread craftsmanship is through direct demonstration, being craftsmen ourselves.

So the final message I wanted to give is: Don’t give up, the change is slow but it’s already happening. :-)

Caio

[unclebob]

> When I'm looking at what I've found from uncle bob, it seems his
> vision is a world without framework, or use them only when you can't
> do anything else... 

That's probably a bit too strong.  I am willing to use frameworks when they can be helpful; but I am watchful for how they could harm me.  I think it's wise to build boundaries between framework code and core business rules.  I don't want my business rules to be deeply coupled to a framework written by someone who doesn't much care about me and my project.