We already have the tools to deliver software continuously and reliably. They are called containers and virtual machines. The problem as usual is not with the technology. If you look back we had SmallTalk virtual machines some time ago that you could pause, ship over the network, and pick up where you left off.
Reading is not the issue as well because most code is terrible and it doesn't matter how easy you make it to read the code I'm still going to waste my time reading it. So I'd say that the problem again lies elsewhere. Few people have the aesthetic sense to write elegant code. It doesn't matter how many tools and abstractions you throw at the problem there are still going to be people writing terrible code.
Writing and reading code or doing anything else with it is in many ways like art. It is also like science and craft and a bunch of other things that require creativity. Even with the accessibility of paints and all the accompanying technology we still don't have the likes of Michaelangelo and Picasso being any more prevalent than they were around the time those guys were alive. Literature is another good example. We teach everyone to read and write but it doesn't matter how much money or technology you throw at it (ebooks, libraries, etc.) we still don't have any more great writers than we did a century ago.
This is not a technology problem. It is a culture and human problem for which you are not likely to find a technical solution.
Most reasonably skilled programmers can read code. They choose not to. Cultural problem not technical one.
I've been in the industry a long time and the best codebases I've seen had a handful of things in common:
* They were written by highly competent programmers who all had an interest in doing a good job.
* The code was neat, well-document, and sensibly structured based on agreed upon standards.
* The programmers writing them weren't forced to inject changes faster than they could compensate for them.
That's it. Most of the disasters in industry are the result of extrinsic demands. People not caring or people. People documenting nothing. People under extreme deadline pressure hammering in something that then has massive, long-term design ripple effects on the rest of the codebase. Do this several dozen times and you're almost certain to produce a disaster and some point.
Therefore, most software problems have to do with people in over their heads or making changes haphazardly to meet deadlines. These cultural issues seem largely to stem from people thinking that writing software is a deterministic process - it isn't, and has more in common with chaotic systems than linear deterministic systems. Hell, I've written virtually the exact same piece of software twice at one company and each time produced both identical bugs and completely new bugs.
We would probably benefit more from understanding what software actually is and educating people about that than attempt to technologize away our problematic understanding of technology.</screed>
> most code is terrible... Few people have the aesthetic sense to write elegant code...
Elegant code does not necessarily mean readily understandable code (or "readable" code). For example, some Haskell programmers like writing extremely elegant code -- so elegant that you can base a whole new (elegant) branch of mathematics on it -- yet it is no more readable than, say, many early BASIC programs.
But why pick on Haskell? I've never seen Microsoft Word's code, but let's imagine it were the paragon of OOP design. Then, I'd like to add a feature similar to the spellchecker, that tests whether consecutive sentences rhyme. Now, I could probably find the spell-checking code rather easily, only to learn that it is attached to the main program via the most beautifully intricate plugin system -- with lifecycle management, runtime loading and unloading and whatnot -- that it takes me a few days only to learn that bit.
The point is that software is complicated, and very non-standardized. Code readability rests only in part on its structure, and a lot on how many "advanced" language features are used, the number of libraries used and their familiarity. You'll probably find "terrible" code that uses a couple of popular, mature libraries, that you're familiar with, much easier to understand than the most "elegant" polyglot codebase (written in both Python and Haskell, because, you know, the best tools were picked for each job) that makes use of 10 of the newest, shiniest libraries you've read a lot about on HN and always wanted to learn but never had the time to.
I didn't say we need to teach people to write elegant code. See my examples at http://akkartik.name/post/tracing-tests. I take this perverse joy in coming up with ugly code that is suited to its surroundings, and I'm extremely well-suited for programming because when it comes to code our aesthetics are like George Costanza's instincts (http://en.wikipedia.org/wiki/The_Opposite).
I want programming to be like reading, with most people able to skim most article-length pieces of prose -- even if it's poorly written -- and get a sense for its global organization. That doesn't require teaching everyone to write like Shakespeare.
Good luck. I'm still not going to read terrible code no matter how easy it is. It took me a while to come to this realization but aesthetically unpleasant code is indicative of the author's abilities and without elevating the level of all programmers I don't see how making code easier to read is going to make much difference. Some tooling might make it easier/faster to come to the conclusion that some piece of software is not worth investing more time in but with enough experience that judgement is not hard to make. Note that LibreSSL was a fork and rewrite of OpenSSL. Even if it was easier to navigate OpenSSL it still would have been the correct decision to scrap large swaths of it because it was horrendous code, easy to read or not.
Thanks for the luck. We might be in violent agreement or disagreement depending on what code you consider aesthetically pleasant. Everyone can agree on the crap, but can you share examples of code that you liked that might help me triangulate on your aesthetics. Alternatively, I'd be interested to hear if my published projects are pleasant or not. To help you triangulate on mine: http://akkartik.name/post/readable-bad.
To reiterate, you're responding to things I didn't say. Code shouldn't have to be perfectly designed to be readable, and nobody should have to wade through utter crap either. Very often code starts out nice when it has one author or three, and gradually turns to crap as more cooks are added. I want to eliminate that dependency on author churn, to have it be beautiful or ugly based on the capabilities of the programmers involved, not on the difficulty they had understanding those who came before. To make progress on this project, I find it most valuable to utterly ignore aesthetics.
I don't think we are agreeing or disagreeing. I do want tools that make it easier to navigate and understand code and I also want cultural shifts in programmer communities that lead to better software overall. I'm just saying the communal aspect is more important than any given programmer's ability to navigate code but the two are obviously intertwined in complicated ways.
That article you linked to (http://alistair.cockburn.us/ASD+book+extract%3A+%22Naur,+Ehn...) connects the dots really well. Programming is really about building theories and then implementing them with computational building blocks and then transferring the understanding of those theories. Short of developing mind reading I think there is an irreducible complexity in that endeavor that is impossible to skirt around.
In light of that article I'd like to amend my comment about aesthetically pleasant code. Some programmers are good at structuring things so that the overarching theory is present throughout all code level structures. That kind of code is both aesthetically pleasant and easy to read. I don't know if this is some kind of special talent of if it can be learned but given that most software is a confused mess I'm willing to bet there is a large talent component.
Yeah, he may well be right and I might be totally barking up the wrong tree. But that just seems so depressing I can't help but tilt at this particular windmill. The hope is that his theory will become obsolete if the activity of programming changes radically enough.
I started out thinking you couldn't solve social problems with technical solutions. Now I think social problems arise in the context of configurations of technical energy barriers. Making something easier can make good behavior more or less likely to arise. So it behooves technologists to think hard about what they make easier. But this is getting abstract, and I need to show examples of what I'm trying, what I'm keeping and what I'm discarding. If you send me an email I'll show you what I have.
>>It took me a while to come to this realization but aesthetically unpleasant code is indicative of the author's abilities
Not necessarily. It can also be indicative of the circumstances in which the code was written. Even great programmers can write terrible code if they are stressed out or overworked. So you can't just look at the code they have written and jump to conclusions about their programming ability.
Reading is not the issue as well because most code is terrible and it doesn't matter how easy you make it to read the code I'm still going to waste my time reading it. So I'd say that the problem again lies elsewhere. Few people have the aesthetic sense to write elegant code. It doesn't matter how many tools and abstractions you throw at the problem there are still going to be people writing terrible code.
Writing and reading code or doing anything else with it is in many ways like art. It is also like science and craft and a bunch of other things that require creativity. Even with the accessibility of paints and all the accompanying technology we still don't have the likes of Michaelangelo and Picasso being any more prevalent than they were around the time those guys were alive. Literature is another good example. We teach everyone to read and write but it doesn't matter how much money or technology you throw at it (ebooks, libraries, etc.) we still don't have any more great writers than we did a century ago.
This is not a technology problem. It is a culture and human problem for which you are not likely to find a technical solution.