BT

Bringing the Domain Back to Software Development

| by Jan Stenberg Follow 34 Followers on Feb 08, 2017. Estimated reading time: 2 minutes |

If you read the business press of today, you will find that the business side of the world sees IT as an impediment that holds them back. Business has been talking about agility since the 80s, while IT started being agile in the early 2000s, David West noted in his presentation at the recent DDD Europe Conference in Amsterdam.

When West, author of Object Thinking, started to work with IT in the late 60s it was in a bank and he was the first employee that was not a banker. Because of this he had mandatory training in banking, 30 hours each quarter. He then became a domain expert that wrote code. This meant he was driven by, and responsive to, the domain, which also was the state of the profession at that time.

As higher education in software engineering evolved, all concerns of the domain and of users was separated from the concern of programming, a separation that caused the business to increasingly view IT as a restriction, rather than a strategic advantage.

During the years, attempts were made to restructure the relationship between IT and the business; object orientation being used to create a common vocabulary being one example. When Domain-Driven Design (DDD) came along, it was also a recognition of the fact that our focus, being exclusively on the machines, was wrong; we need to understand the domain we are working in to build useful systems.

Unfortunately, none of the attempts has had a lasting effect. To find a way forward West notes that we need some prerequisites. Firstly, we need a better understanding of systems and how they work. Secondly, we must turn our backs on the machine, and instead focus on the domain. He also notes that most of the problems we have in computer science and software engineering is not intrinsic to the problem we are set to solve, but to the implementation we are using when trying to solve the problem.

West emphasizes that being a master programmer is of limited use, if that’s all you are. Good design and great software comes from diverse teams, from people with multiple skillsets, people with T-shaped or Pi-shaped skills who are experts in one or two areas but also have some breadth and the ability to work with experts in other areas. One of these areas West especially highlights is biology, where he finds many useful metaphors for solving problems.

According to West, the very first thing we need to do is start reading, primarily about the domains we are working in. If you are in banking, you should read about banking and then about business in general, especially subjects that have some relation to the domain you are in; for banking that can be marketing and management. West also recommends reading about how business is adapting to change. However, he does also note the importance of reading for fun, something unrelated to your work.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT