BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Bringing the Domain Back to Software Development

Bringing the Domain Back to Software Development

This item in japanese

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
Style

BT