I expect this is said in client meetings all the time. You hate to be a lowest-bid commodity supplier; you want to play up your long-term high-touch relationship and understanding of the client's business. "The code for this application is just one of many tools along the way to our enabling your digital transformation strategy."

I've never heard this in any client meeting and suspect most clients wouldn't take this very well.

Clients are interested in a working product, as quickly as possible and as cheaply as possible. It's hard enough already to convince them of the importance of non functionals such as reliability, maintainability and security.

I had initial thoughts, but I read the article and noticed the author is an academic.

The author mixes up How and Why of software engineering. Learning is part of the How of software engineering. The Why of software engineering is to develop and deliver solutions to business clients. Most business client don't care if you learn something or not, they expect results.

True, I am an academic (btw is that something to be ashamed of?), but I have worked 10 years in the industry - and am still doing projects for real clients.

I agree, I could have differentiated a bit more on the How and Why, but I think in the end it applies to both: do the customers REALLY always know what they want? They think so, but it is not really the case. Often it is muddled under a premature idea of a solution the client already thought up. Therefore, its better to start with a minimum viable solution (prototype) so the client actually sees and touches something tangible, which will very often change their idea of what they actually REALLY want.

Software development is a knowledge business, as Fred Brooks has realised nearly half a century ago [0]. In order to build any kind of working software, you have to learn a lot of different things first, on all levels -- from how to write a list comprehension in Python all the way to why a certain end-user needs a particular functionality.

[0] https://en.wikipedia.org/wiki/Brooks%27s_law

Strongly disagree. Why of software engineering is to formalise business processes so they can be replicated and automated. The code is most definitely "how" we get there.

I feel that you definitely could say this of art like drawing or writing, but not software. Programming is a tool I use to meet an end. I decide I want to have this program, spend a week writing it, and have the program. That's using the skills I already have. I don't care how much I improve, because to achieve the result I wanted I didn't need to hit the books and practice for a month, improve, and come back again.

Maybe that's why I find it so hard to get into art.

Why can't art be the same?

I used to say "I can't draw", then I sat down and spent about five hours looking at how to draw books, working through the basics, over the course of about three weeks.

Now I can draw, repeatedly, to a certain standard. If I want to learn more I could, but it isn't strictly necessary.

> I decide I want to have this program, spend a week writing it, and have the program.

How do you decide you want 'this program'? Why not a slightly different program, or the same functionality implemented with a different approach. It boils down to research and learning, especially for non-cookie cutter projects.

In my experience, it works out better to know the truth and act in accord with it, however inconveniently it contrasts with how you would prefer things. The client probably should realize the hubris of the endeavor and expect failure.