Programming is important – really important
I wrote this in response to a comment on my post about Dreaming in code, but I wanted to expose it to people who view this via RSS, so here’s the comment and my response.
Finally, something I can talk about.
I disagree totally.
Programming is not about code.
For me, a program or application doesn’t live in the computer. It is not the bits and bytes. It extends much, much further.
For me, an application extends across everything the code affects. Not only is it the code, but it is also the users’ and the stakeholders’ mental models, processes and understanding of what the code does, what their organisation is and how to use the code to enhance their organisation.
Applications extend beyond computers into the people.
Example – a content management system is more that just the DotNetNuke code. It is also assigning the roles of writers and editors, it is understanding the people who will read the content and shaping the navigation and tone of the articles appropriately, it is teaching everyone in the organisation that they can request changes, and communicate their important stories with the world through the web.
When I am writing an application, I am not writing code. I am talking to people, I am trying to understand their issues, ideas and viewpoints. I am trying to work my way to the root of the problem. I am working out what questions to ask, talking to end users and training people to see things in different ways.
The application exists both in the computer and in the minds of people. As application building is not about code, it’s not creative writing.
You don’t look at the source code for great pieces of software. Or look at the architecture of great pieces of software. You don’t look at their design.
What are patterns if not examples of great pieces of software and design?
What is MSDN – the magazine? Yes it is a Microsoft advertising vehicle, but it still has great code to read, understand and appreciate.
What are all the sites, forums and blogs on coding (including this one) but a sharing of knowledge on building applications and computing?
I use some of these words differently to you. I don’t think a ‘program’ is that same as an ‘application’, and I don’t think that ’software/application development’ is the same as ‘programming’ at all. So I agree with all the things you say, up to the quote, about applications and application development, but at some point in application development we need to do some programming and to me that is absolutely, positively, by definition, about code. Programming isn’t the only thing that we do in application development, but it’s an important thing and I think there is a tendency to devalue it; to treat it as a typing exercise in which all programs that perform the same function are treated as equally worthy (you didn’t say this, but I hear it a lot). I think application development would benefit from improvements to many disciplines, but I feel that programming is one of the most neglected disciplines at all.
When we write a program we write for two very different audiences – the program needs to be understood by the computer, which is apparent when it does (or doesn’t) perform the expected functions, but it also needs to be understood by human beings. Most of our effort currently goes into pleasing the computer, but in some sense this is the easier of the two audiences. Gabrielle is saying (and I agree strongly) that we need to put more of our effort into satisfying the human audience for code. I’ll assert as a corollary that finding ways to make code more expressive to people will also make it easier to write code that satisfies the computer as well, but I can’t offer a proof in a mathematical sense.
As to what are patterns, and the code in places like MSDN and most web sites (including this one), they bear the same relationship to great programming that a power tool catalogue has to great building. They’re focussed predominantly on efficiency, and on satisfying the computer, not on the aesthetics of programming as it’s experienced by a human being. Christopher Alexander presented a keynote at OOPSLA many years ago, which I had the honour of attending, at which he said that he was ashamed of the way that the software community had applied patterns; that the heart of his idea was creating environments that appealed to our humanity but that software patterns has been sterilised – stripped of aesthetics and reduced to the equivalent of screwdrivers (my words, not his, but I think I’m faithful to the intent). Show me an article, or rather not one exceptional article but a body of work, that addresses different ways to name variables within the same programming idiom to improve expressiveness, or how to write code that brings a smile to your face, and we’ll be heading down the path that Gabrielle is talking about, and we’ll have taken one tiny programmatic step towards Alexander’s goals.
You once asked me in email why I went back to uni to study psychology – my reply should have been because I think it would make me a better application developer. If I wanted to become a better programmer I wouldn’t choose psych, I’d choose creative writing and literature, and that I haven’t speaks to lack of time and dedication to my craft, not to a lack of need.
I use some of these words differently to you.
Welcome to the post modern world.
Program vs application
I think I can agree to these definitions.
Programming = writing code
Application development = producing something which produces business value
Programming is a part of Application Development, as is use case development, brainstorming, working with ideas.
From my viewpoint, (controversial I know) programming is only a part of application development. I see it as a dying part – as described by you above. The beauty of it is being eroded by commercialism with its quest for efficiency, so that it becomes inert and lifeless.
And, I’ll go further, if it is not dying it should be killed off. !! The future lies in application development, not programming.
(Shocking I know, and if I get time later I’ll write on it, otherwise in will be expanded on in later comments – no doubt.)
—
I don’t see how you can hold both Agile ideas – with its ideas that the only thing of value is working code and business value – and this idea about the value of artistic code – where value is contained in the coder’s experiences. The two seem contradictory.
Your thoughts?
—
Finally, I have worked both as a writer and a coder. See Personal acheivements at http://davidrcollett.com/
For me, writing is more like application development than it is like programming. In writing, you work with the swirling mix of ideas and conventions, to bring out some beautiful abstraction that no-one else has seen before – rather than just write words on a page.
Is your experience of writing this blog similar to your experience of coding?
Hi Dave,
Where does the agile manifesto say that the only things of value are working code and business value? I read the manifesto and I see four things that they value. Team members do interact and communicate through code, so it seems reasonable that communicating better through that code is a reasonable goal for an agile team, especially if that communication makes code easier to maintain (ie. keeps it working).
Also, as a tester, when I work on agile projects I do all of the things that you describe as application development. But I don’t program production code. And without that, there’s no application. I may not fully understand your point, so I look forward to you expanding on the death of programming
I agree programming is only part of application development, but I view it as a critical part. No matter what we do, someone will need to reduce our desires to instructions to a very literal minded computer, and that will be called programming. The future of application development lies in programming, whatever that looks like.
Even if the future was different, that wouldn’t stop me from trying to use the current tools to the best of my ability while I waited for the future to arrive. And if commercialism erodes the beauty of development, then I think that is commercialism’s loss. The people I know who are the most productive applicatin developers also write the most beautiful code. I don’t think it’s a coincidence.
That’s how I can hold both these agile ideas in my head _ I don’t find them contradictory at all. Perhaps if someone finds they can’t create beauty, then they benefit from denigrating it, and believing it has not value. I don’t think that applies just to programming.
I find the experiences of blog writing and code writing to be very similar, on the good days in a positive way, and on the bad days in a negative way.
For me, my catch phrase is:
“The past of application development lies in programming, whatever that looks like.”
This may be one of those YMMV moments.
—
Perhaps if someone finds they can’t create beauty, then they benefit from denigrating it, and believing it has not value.
That’s a bit harsh. It’s saying:
If you don’t appreciate thing I decree as beautiful, it’s because of a failing in you.
It’s very similar to the idea “You’re either part of the solution or the problem.” but it’s being expressed as “You’re either an artist or a talentless denigrater”
I hope you don’t bring this attitude to the table when working with others. It sounds very hard to work with.
—
The drawbacks with code artistry are:
Code artists, people who express themselves through code, will see all solutions through a filter of code and programming. I think the quote (rejigged) is:
“Code artists believe that all problems can be solved with just one more level of indirection”. This approach to problem solving is short sited, as the best solutions come from looking at a problem from may different angles (think Edward de Bono).
Aesthetic code is not the same as commercially valuable code. They have a different criteria against which they are judged. These criteria can be expressed as:
Aesthetic code pleases Steve.
Commercial code produces the greatest monetary value (through being cheap and making a lot of money for the owner).
Sometimes there will be code which meets both criteria. This is code that both pleases Steve and makes the most money.
Sometimes meeting one criterion will create code which rates much higher on the other. For example, by writing code with the aim of pleasing Steve’s aesthetic, you also find that you write code that makes the most money. And, the collorary, by writing code that makes the most money, you may also find that it aesthetically pleases Steve.
But the two criteria are different, and it won’t be the case that every piece of code meets both criteria. There is a term for this. I believe the term when some produces something more beautiful than is required is over engineering.
A third problem is “Whose aesthetic?” Just as something that is beautiful to Picasso would not be beautiful to the person on the street, something which aesthetically pleases you, may not be beautiful to other programmers. Who gets to be the head artist?
—
Finally, if you really want to see how important beautiful code is, put it as a feature to the client. For example, put the following user stories to them:
US1: Search for person returns all articles written by that person
US2: Steve is aesthetically pleased with the code he writes
US3: Search for title returns all articles with that title
You’ll probably find it never gets selected.
I don’t think I said “If you don’t appreciate thing I decree as beautiful, it’s because of a failing in you” at all. That only leaves one explanation for the lack of appreciation, when there are many possible interpretations – I only allowed for the existence of such people.
I agree that aesthetic code is not the same as commercially valuable code, but that doesn’t mean the two things aren’t correlated. In my experience they are highly correlated, so the assertion that ’sometimes meeting one criterion will create code which rates much higher on the other’ is correct but potentially misleading (depending on how common people think ’sometimes’ is). I think most of the time aesthetic code is also commercially more valuable. Beautiful code has fewer defects, it’s easier to change, and has lower total cost of ownership.
Do I bring my harsh attitude to the table when working with others? If you mean the idea that code beauty is important, and lack of tolerance for ugly code, yes, I do. Many programmers behave as if code aesthetics and commercial value are completely uncorrelated – I think they are wrong. Not that they have a different perspective – they’re wrong. If I’ve been given responsibility for a delivery, which is often the case, I need the team to act as if they believe in the correlation, otherwise I personally can’t take responsibility for the outcome. Someone who doesn’t want to share in this team position isn’t part of my team, and I’m ok if this is perceived as harsh. I’m also past the point in my career when I wanted to work with everyone, regardless of their beliefs and attitudes. I’m sure some people find this very hard to work with – I don’t mind, I probably find them hard to work with as well. However, before I come across as an unadulterated ass, I don’t find my attitudes clash with most people. YMMV.
Thanks for the user story example. It’s broken because it’s mixing features and constraints, but it’s an interesting point. I think that every customer or manager who has chosen me as a team leader or a mentor has implicitly chosen the constraint ‘Steve is aesthetically pleased with the code that’s written – we accept his balance of aesthetics and commercial value’. Doesn’t make my preferences the only possible choice, since there are lots of successful team leader who have other aesthetics, but I think it refutes the ‘never selected’ premise.
Nice. I think I’m stumped at this point.
I liked the way you delved into the greyness of words like some, most and is.
I also liked your ideas around leadership – which I can’t argue with. Part of leadership is defining and enforcing boundaries.
However, I think you run a risk arguing that aesthetic code is highly correlated with commercial value.
If you keep strengthening the correlation, you’ll reach the idea that beautiful code is always commercially valuable. At that point you’ll have reduced aesthetics to commercial value – which I’m not sure you want to do given your earlier arguments.
This is a great discussion.
Object Mentor have a blog entry along similar lines here http://typo.objectmentor.com/articles/2007/04/16/code-is-a-liability which I hope is of some value to this thread.
Thanks, James L.
One of the benefits of arguing on a blog is that it launches so many other people’s thoughts and ideas.
There now seems to be many concepts in the mix:
functionality = the thing the businesses value.
coding = which Steve argues for, which produces code, and is a literary activity – like creative writing
and
code = which the linked author discusses and may be a liability.
I think the way all three are linked are:
* applications are collections of functionality
* functionality are actually ideas – existing in people’s heads, mental models and beliefs about the world and how it works
* functionality is made tangible by coding – it becomes something that people can interact with. It has been dragged from the world of ideas and made solid.
* coding produces code
I believe I favour the concepts at the top, Steve favours the concepts at the bottom.
I capture ideas for applications and try to produce their functionality through systems like DotNetNuke and other pre-written systems.
Guessing from the Cogent website, Steve works in making the code better (i.e. refactoring and patterns) and changing functionality into code (agile methodologies) – specifically to make it easier for programmers to go from functionality to code.
Would you agree, Mr Hayes?
—
This bit supports Steve’s argument:
Hand-crafted code is almost always more readable, smaller, more optimal, more focused, more literary in its style than generated code or funky data tables. Since there has to be code, it might as well be the best code we can write. Coding well takes human beings who value minimalism.
and this bit supports my ideas:
Our bosses and clients will pay good money to get the functionality they want, and they want it right now! If we could give them what they want without writing a line, it would be a tremendous win. If we could do it with one line or two lines of well-considered code, we would be heroes! Why is doing less so valuable if code is an asset? Clearly less code is better.
functionality = one of the things the business values. They may also value maintainability, flexbility, and almost certainly productivity
coding = a creative, expressive activity. Capturing ideas in ways that are understandable by both people and computers. Currently this is often text. Synonomous with programming.
code = the outcome of coding, the thing that needs to be understood by people and computers. This may be text, pictures, code or configuration.
I don’t “favour” one thing “over” the other – I think they form a web, and the route to improving delivery of functionality in a productive way is to improve the code, by being better at coding. Means to ends.
The ObjectMentor author is struggling to find the right words for some difficult concepts, and I think they make some missteps. I’ll try a different metaphor for a while.
Let’s look at mining iron ore (why?, I don’t know). The ‘functionality’ to be delivered is iron ore, extracted from the ground. If we could magically do this cheaply that would be fine (not that magically doing it very expensively wouldn’t be fine – that’s why productivity needs to be part of this discussion). Right now, the way to get the iron ore is to build big extraction machines. Fewer machines would be better, but the machines are still an asset (in the economic sense), not a liability. There are costs associated with maintaining these assets – broadly speaking this is the ‘cost of carry’ for the asset. Poorly made machines may be cheap to buy, but expensive to maintain. A well made machine may be more expensive to buy, but cheaper to maintain. Some suppliers have special expertise that lets them create moderately priced machines that are also cheap to maintain. Many assets have a cost of carry – my wife makes jam, her stock in hand is an asset, but she needs to rent storage space so there’s a cost of carrying the asset. If the cost of carry is greater than the income generated by the asset the it’s an uneconomic asset, which is a liability.
We want functionality in the hands of our customers. If we could deliver is magically (without code) cheaply, that would be great (but not if this was expensive). We build lots of code, which when executed delivers the functionality desired. Less code would be better, but the code is still an asset. If there are no changes the cost of carry for the code is zero (this is a wonderful part of software) but we usually have defects that need to be fixed or need to adapt it to changing contexts, so there’s a cost of carry. Some code is cheap to make, but expensive to maintain, some code is expensive to write, but cheap to maintain. Some coders (programmers) have special expertise that lets them create easily maintained code at moderate prices. These programmers have invested in the skill of programming, breaking the false dichotomy of cheap+nasty vs expensive+beautiful.
The analogy didn’t work for me, I’m afraid. I’m sure you’re right, but I found it hard to penetrate (too many ideas too quickly probably).
But I think I can use it.
Consider this:
Steve is the owner of the iron ore. His concerns are:
* understanding how much iron and what sort of iron ore is needed by his clients
* mining the iron ore as cheaply, quickly and risk-free as possible.
I’m the guy the king comes to and says:
“Dave, the orcs are coming to attack. They will be here in 3 months. What can we do?”
I reply:
“Sire, we could do what we normally do and get stone from the quarry, and make pointy spears. That would be good for these reasons, but that would be bad for those reasons”
“Or, there’s a new guy in town, Steve, who’s set up an iron ore mine. What we can do is buy his iron, get it smelted in Narnia and made into swords in Middle-Earth. We can also get this guy from EarthSea who can give the troops a quick lesson in sword fighting.”
“This will cost you a little bit more than the stone spears, but you’ll kick those orcs back to Lilliput. And, we can raise that extra money, by having some of our quarrymen teach Steve some better ways of mining.”
In terms of my role in IT I hang around the court and work out what the king really needs, and then tell them ways they can use IT (the iron mine) to get what he wants. It’s big on people and thinking skills, lower on coding/coding management skills.
—-
Refining my earlier position, I think where Steve and I differ, is that I have another layer above functionlity in my definition of what IT is. For me, there exists a level of IT which invovles working out what the real problems a business faces are and what can be done about them from an IT perspective.
For example, I belong to a body corporate – which before I joined spent most of it’s time internally fighting.
Using my IT skills, I realised that this was caused mostly because of communication problems – in that no one could communicate easily with the others on the body corporate. For example, there was never enough time at the annual body corporate meeting. The standard body corporate structures weren’t working in keeping people informed and involved. External meetings didn’t work – because not everyone was available at the same time.
My solution was to get everyone on email and show them how to communicate using it. The result was (and is) a functioning body corporate. Once the communication lines were opened and people became used to it, we were able to work things out semi- intelligently.
Here, I used an IT product (email) to come up with a solution to a problem which didn’t involve coding.
This is why I believe we have different focuses – mine more on the how IT is used, and Steve more on coding and code. Which is OK and probably reflects our different personalities.
It doesn’t need to reflect different personalities, it’s sufficient to represent different roles in the overall activity. That’s what I meant when I send I don’t “favour” one thing over another.
If the business is making spears, then mining the ore is part of the process, and I’m interested in being the best miner that I can. Doesn’t mean I don’t appreciate the guy who makes the spear, or the guy who uses the spear either.
You started this thread with “programming is not about code”. I still disagree with this strongly. But your last example isn’t about **programming** at all. If you want to say “leveraging IT isn’t about programming”, I’m all in favour of that, but it’s outside the scope of the original blog post.
Would business be able to make better use of IT if the things they needed already existed and could simply be used? Absolutely – it would be like having a bunch of spears already laying around. I use MYOB to support my business in exactly that way, sans programming.
For whatever reasons, many businesses can’t find the sofware they want, and it needs to be built. So all of a sudden we’re programming, and it’s all about the code.
I’d be happy if we didn’t need programming and programmers at all (there are plenty of other things to do), but while we need programmers I’m going to be the best one that I can, by continually learning and writing the best code that I can. While we need new applications, programming is important, really important.
I think we’ve come full circle…
I said at the beginning:
Programming is not about code.
For me, a program or application doesn’t live in the computer. It is not the bits and bytes. It extends much, much further.
For me, an application extends across everything the code affects. Not only is it the code, but it is also the users’ and the stakeholders’ mental models, processes and understanding of what the code does, what their organisation is and how to use the code to enhance their organisation.
Applications extend beyond computers into the people.
Going back to the iron ore analogy, the program/application (for me) is not only the production of the iron ore, it is also:
* the smelting of the iron
* the production of the swords
* the training of the soldiers
* the king’s idea that the orcs will attack
* the king’s desire to repel them
* the idea that they can be repelled by trained soldiers with iron swords
All of these things can be worked on, developed, enhanced and strengthened.
Hence, for me, as the application extends outside coding and code into people and coding is not as important as other parts of application development.
I know this is not your idea of what programs, applications and code are, but as you say, YMMV.
—
For me this is what blogging is about. Because blog posts are so limited in their nature, we do not ever succeed in changing the other person’s ideas, we just succeed in refining our own.
I believe I only have a problem with the way you are using two words – program and application.
Though it may surprise you, I agree completely with this sentence – “… the application extends outside coding and code into people and coding is not as important as other parts of application development”.
But you’ve used program and application interchangeably twice, and I think this is muddled. I don’t think that I can have sensible discussions about my craft unless I try to be clear about the words that describe it.
“For me, a program or application doesn’t live in the computer. It is not the bits and bytes. It extends much, much further” – I agree completely if you remove the word “program”. A program is an artifact that exists only in a computer, the same way that words live in a book. The program, just like the book, may have an *impact* beyond this, but that’s a manifestation of the ideas and use of the program, not the program itself. A program is like a screwdriver, a chair, a joist – it’s a crafted artifact that is usually part of something larger. I’m happy to call the larger thing the application, the system, the business, or many other terms since it’s a large thing viewed from many perspectives.
So in your fantasy world analogy, I think the application is the ‘whole thing’, which is what I think you are saying. But ‘programming’ is the mining, which is where we started. Since everything is interdependent it’s critical, but paradoxically not as important as the other things (such as military strategy).
So if you say “creating applications is not about coding”, I agree. If you say “creating applications is not about programming”, then I agree. But when you say “programming is not about coding”, I can’t agree.
If you think that a program is the same as an application, then we’re done and we’ll never agree. But I hope that most software developers have a distinction between a program and an application, because I think you can be good at both, but they require very different skill sets, so anyone who masters one and thinks they have mastered both is doing themselves and their clients a disservice.
So now the post should be called – words, they’re really important.
I agree.
We have different ideas about what programming is, hence our different approaches to IT, and our different business models for our businesses.
Is there room in the world for both of us? Yes.
Will our business make us money? I hope so.
Does it matter that we have different ideas about what a program and programming is? No.
Where will I go from here?
I’ll acknowledge that I favour the application of code over the creation of code, and focus on the former rather than the latter.
(The idea is that if you focus on the things which appeal to you most, you do better than trying to be something you don’t really agree with.)
Hi,
I am interested in purchasing text link advertising at some specific pages
of http://www.cogentconsulting.com.au. Let me know if you
are interested so that wen can discuss it further. I can make a good offer
to make it worth your time.
Let me know!
Thanks,
Robert