An intent to specify and control the behavior of digital computers. That could be an answer to the question: What is a computer program? That is to say, a computer program is an intention and the rest are all annotations (in analogy to that summary phrase of what is western philosophy in regard to Plato writings).
Among those annotations are those related to whom the intentions come from; in other words: who should design computer programs and their conglomerates also known as large-scale software systems? Which should be their profile, mental education and professional background?
There have been answers ranging from programmers to architects and others in between with a variety of professional foundations, but what has worked for mature professions in their forming stages is the philosophy of science in general. I hope our infant industry comes to grips with that same idea.
I found the following writings in an old file somewhere in an old hard disk, unfortunately, the file has no references to the original persons the writings came from. If the author is listening, please leave a comment so I can quote you properly.
“There are certainly people who think more about high level structure than they do about low level details. This is a valuable talent, and not one that should be scoffed at or discounted. Unfortunately, in some circles, it has become popular for people with these talents to divorce themselves from code. The term “architect” takes on an aura of authority and power, whereas a coder is deemed a lowly laborer, a dime-a-dozen worker bee.
In reality, while the difference in talent is real, the polarization into different roles with different authorities is harmful. Those folks who are good at modeling and architecture must still remain grounded in code. For their skills to remain relevant and useful, they have to keep in touch with the medium they are trying to create structures for. Likewise, the programmer who divorces himself from concerns of architecture harms himself and his team by abdicating responsibility for something he is in an intimate position to control. There is a way for these two talents to work well and closely together, but they have to put forth the effort to understand each other.”
“A scientist is someone who employs critical thinking to data. Someone who reads the eXtreme Programming book and gets angry is not applying critical thinking to data. They are reacting emotionally because eXtreme Programming does not fit into their view of the way the software world should be. This is a credulous attitude, and not the way a scientist should react.
In some ways eXtreme Programming is a translation of the scientific method to software. In science we take tiny little steps towards gaining knowledge. Each step is the result of some experiment we run. Each step is verified by data. So too, in eXtreme Programming, we take tiny little steps, each step verified by tests.
There are some folks who have decided that taking tiny steps verified by data is the wrong approach. They think that software should be built by thinking about it up front, creating an architecture, and a design, and then, finally, once all the hard decisions are made, coding it.
This view is similar to the view that some of the ancient Greeks had. They scoffed at experiment and data. They believed that the structure of the universe could be worked out by sheer thought. And so they decided there were five elements, earth, water, air, fire, and ether. And that the universe was constructed of spheres made of these elements. Any element moved away from its sphere tried to get back to its sphere. Thus, stones (earth) fall, smoke (fire) rises, etc. It all made sense. It was all wrong.
People got angry when they read Copernicus. They got angry when they read Galileo. People get angry when you challenge their world-view. That’s OK. There are enough critical thinkers out there. Bit by bit, the truth and falsehoods about eXtreme Programming will be sorted out.”