Sunday, April 08, 2007
Scribes and Programmers
A long time ago, there weren't too many people who knew how to write. So if John Ancient wanted something written he would visit the local scribe and pay a fee. I am not sure if the scribes ever formed a guild but I wouldn't be too surprised.
These days, if Joe Modern wants a program written, he needs to hire a programmer (or a bunch of programmers) who'll translate his needs into the appropriate incantations.
Imagine a world where a majority of people know programming - perhaps not enough to write an operating system kernel but enough to write a basic Rails application - say a ToDoList application. (I did say "imagine"). How would programmers evolve?
I think they will become largely "post technical" - a term used, sometimes pejoratively, to describe developers who've moved away from code-centric jobs. The term is mostly applied to folks who go on to become managers, an idea which is looked down upon by some developers.
In a world where most folks could program, post technicalism would be the norm. A large chunk of present day programming jobs would simply disappear. You can't get a job these days if you "know all 26 letters of the English alphabet and can form grammatically correct sentences in English", which is the level at which a large majority of "professional" developers "program". Knowledge of writing is required but not sufficient for a paying job today. A doctor needs to know how to write but he also needs to know much much more. Musicians, biologists, teachers - all could do with a basic knowledge of programming. Perhaps basic programming skill should be taught just like reading and writing are. Then the idea of writing a quick script to generate a graph from a database wouldn't be some kind of exotic skill , but a basic competence expected from educated people.
Would this disappearance (or submergence below the awareness level) of programming skills be a bad thing? Not really. Technological progress has rendered many jobs obsolete over the centuries and humanity has coped very well.
Also, there would still be a need for people having extremely high levels of programming ability, just as there are professions that need extremely high levels of writing/communication ability - think copywriters or diplomats. The folks who focus on algorithms and networks and compilers and other 'deep programming' would probably survive just fine.
Of course the writing analogy can't be stretched too far. Documents are created by one person or a few people at most, over fairly short periods of time. Most significant programming projects involve large groups of people working on the same codebase for significant amounts of time, sometimes decades. The main challenges (as measured in terms of completion and impact of the project) are about people issues - how to hire them, how to retain them, how to make them work together.
And this organizational difficulty of managing large groups of people and getting them to build something coherent is the space in which, at present, many snake oil vendors (think "lean " or agile") thrive. The presence of snake oil is often an indicator of a fundamental and intractable problem. So even if a large number of people knew how to program, the organizational aspects will need hands on resolution. Thus the "project manager" type person would be alive and well. The VB/j2ee/dotNet folks are the ones who'd disappear.
But is the "manager dude" the only evolutionary path available to code jocks? I think not. For example, the world of science and engineering (modulo software "engineering") would still be open. Yes, there would need to be a lot of study - mathematics and statistics and the sciences and particular engineering domains - you won't be able to grab a book called "Java X.Y in 24 hours" and get a well paying job. People wouldn't be able to make money doing the equivalent of writing other people's letters for them. But I suspect there will be a lot of fascinating problems to solve, even in our imaginary world.
Even in a world where everyone codes, the "path of the suit" would still remain the Dark Side. You would still need to think long and hard and try to balance gain and loss before setting out on that path.
Subscribe to:
Post Comments (Atom)
15 comments:
I have grown up watching everyone who goes through math undergrad courses being inducted through a semester or three of programming, a mixture of C and Mathematica, and yet out the other side most graduates swear black and blue that they will never code again.
What is it that us comp sci people are doing wrong? What have we forgotten to do? Why is programming so inaccessible for most people?
I mean, sure, I earn an income as one of the much maligned J2EE code weenies, but I'd much prefer to spend my time coding compilers and what not. And one of the out standing problems i see is building a programming environment that normal people can use. Well, apart from excel.
Thoughts?
@brett,
As a member of the self taught brigade (and yes once upon a time I was a j2ee jock as well), I am the wrong person to ask as to why Comp Sci departments fail in making programming interesting to people :-) .
I would imagine that the place to teach programming would be at school.
Algorithmic thinking is probably something that everyone should learn, not necessarily graduates.
You are aso right about the lack of a good environment.
Python and Ruby are much better languages to start with, than say Perl or C.
I've had some modest success in persuading non programmers to give Python a try.
But I sure as hell don't know what the right answers are.
An interesting article from about a year ago on the difficulty of teaching programming in schools:
http://www.cs.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf
Seem relevant to your question brett.
Most adults in the US can write, but there are an awful lot of people who make a living from some sort of writing - whether secretaries or best-selling authors.
Most adults in the US can drive, but there are an awful lot of people who make a living from some sort of driving - whether dropping off deliveries or racing.
You don't have to look towards high-end engineering or anything to know what programmers would do in a world where most people could program to some level. Programmers would do the programming most people weren't skilled enough to or didn't want to spend the time doing. Just because an executive can put together a to-do app doesn't mean he's going to sit down and code up the company's intranet - if only because he's got better things to do.
@eric,
You miss the point.
The point is that driving(say) is common enough knowledge that the average person *has the choice* of hiring someone. Programming is sufficiently uncommon knowledge that the average person *has to* hire someonel else.
Of course goods and services will be traded. The laws of economics don't disappear when most people know how to program. But that wasn't the central point of the article.
How many people write theri own letters vs having secretaries? How many people drive to the nearest walmart to buy supplies vs hiring a cab?
*That* was the point.
Thank you for your thoughts.
Brett's comment "Well, apart from Excel" is kind of like saying, "well, apart from pens, there's no good way to write."
Since 1978 (yes, for 29 years) there's been a powerful tool that has allowed almost anyone to program. While most Java and Ruby and PHP coders wonder what would happen if someone magically invented a way for "normal people" to write programs, the rest of the business world is driven by spreadsheets.
Maybe we should be asking the question, "how can we make Excel a tool that allows a broader range of expression without destroying it as a true business 'domain specific language'".
>at present, many snake oil vendors (think "lean " or agile") thrive.
While I am sure there are snake oil salesmen pushing agile and lean, I believe there are *more* of them (think pmi, six-sigma, etc.) pushing other kinds of methodologies which involve a lot of up-front analysis and design and which generally come down to creating all sort of wondrous documentation. If you document everything, you couldn't possibly go wrong.
Hmm, what's my point? I guess I take some offence that you seem to imply that any advocate of a more empirical approach to developing software, which is what the agile/lean stuff is ultimately about, is a silicon snake oil salesman.
There are lots of examples of people who are not programmers developing various kinds of software; sometimes with scripting languages like perl; sometimes with a spreadsheet like excel; perhaps also with rad/case tools - say in the domain of math (mathematica), graphics, gis, various kinds of engineering... As soon as one begins to develop tools that a) require more than just combining pre-made building blocks in very simple ways and b) need to be used and/or developed by more than one person, I think that's where it will always be quite difficult to get away from hiring specialists whos main job is programming itself... At least my opinion. I do think there's still lots of room
@vladimir,
Obviously what "is" or "is not" snake oil depends on experience.
In my opinion "lean software" is pure snake oil. No respected *software developer* (vs "process consultants" - people who make a living by selling "coaching" to others) has validated "lean".
"Agile" is a more complicated case. There is a lot of goodness in extreme programming etc. BUt multil level marketing scams like Scrum are alive and well, too. In my experience, the "scam" aspects of agile overshadow the practice of agile, at least here in Bangalore.
YMMV.
In a nutshell unless you are one of the "agile consultant/coach" brigade you don'tneed to be offended. I am not targeting *advocates* of agile. I AM targeting *sellers* of agile (or any process for that matter).
PS: the argument that there are *more* snake oil sales men in PMI does NOT weaken my argument. :-)
I agree that PMI/CMM/ISO are old and established brands of snake oil wheras, agile and lean are the upstart newcomers.
I don't really know much about lean. I listened to a talk by Mary Poppendieck and I have to admit I saw little relevance to software development. I do really like Scrum though. I think the burndown chart is a really clear way of expressing velocity. You don't need to worry about whether you're counting ideal hours or jelly beans - you can *see* that a task is taking a lot longer than was originally planned and you can also see the effect on the overall delivery by projecting a linear regression line. I had never seen such a chart before I read the scrum book and I think it's a wonderful, simple idea - the kind of thing that makes me wonder how come I didn't think of it. May other aspects of scrum seem very common-sensical to me - developing a product backlog that gets reviewed after every iteration; showing the customer the "red" line that defines the border between things that can be accomplished and things that fall out of scope given current estimates... Now, implementing scrum is a different matter, but the basic idea of it seems to be quite wholesome...
One thought occured to me after reading your posting - what's a snake oil salesman? If you believe in what you're selling, does that make you a snake oil salesman? Or do you have to believe it's nonsense to qualify? And what if you believe it's bunk, but it really turns out to work anyway? :)
["Agile" is a more complicated case. here is a lot of goodness in extreme programming etc. BUt multil level arketing scams like Scrum are alive and well, too. In my experience, the "scam" aspects of agile overshadow the practice of agile, at least here in Bangalore.]
Well, you know... Programming has always been the wild west. It still is. There are some great people in the software development community, but there are also a *lot* of incompetent hacks and dishonest hustlers. Bangalore must be the wild west of the wild west! In lgiht of that, what you're going through is no surprise to me - it's bad enough in north america where things have had more time to stabilize! On the other hand, I imagine it must be also a place of opportunity where someone with real capability and integrity may really be able to make a difference. I know you plan to go to grad school, presumably in the states, which is great and I encourage you do go for it (and stop waiting around already for heaven's sake!), but if you do decide to stay or come back, perhaps you can establish something in Bangalore that represents your vision of an honest and effective approach.
@vladimir,
Belief and effectiveness are orthogonal, I agree.
I would rather that all these vendors and salesmen of methodologies write some significant code first, before telling the rest of us what to do.
Aside from Ward and possibly Kent (as you pointed out in a comment on another entry) most of these "agile gurus" and "luminaries" are rather naked when it comes to good code.
And Bangalore is a long away away from producing significant software. Taking out the trash for the West is still too lucratve (with a very few honorable exceptions), but that's another blog post ;-)
Thank you for your encouragement. Much appreciated.
Sorry for the profusion of comments. I guess I am in a chatty mood. :) In regard to qualifications to promote a given approach to software development, I think my criteria are a bit softer than yours.
For example, I've worked in software development for close to 10 years and I've tried to seriously study my craft during that time. I've made some breakthroughs over the years and I consider myself to be quite a decent developer now. Not a genius; not someone who can write an advanced compiler or who has developed a large public web site with all the attendant performance issues, but I've worked on a variety of real systems in the real world. I don't put myself out there as some sort of guru, but I do think I have something to offer other development teams based on my experience. By analogy, assuming that someone in the agile community (or any other for that matter) proffers his/her ideas based on a reasonable amount of experience, I think that's ok. It isn't necessary to be the head programmer at Id Software or NASA's JPL.
Real business sofware is quite a challenge. It's not as much of a challenge as the most advanced systems we've got, but it's still not trivial, at least I don't think so. If I were advising people who developed software in an area radically far away from mine, I would try to be humble and to make it clear that my ideas may not necessarily apply to their circumstances. That said, a lot of programming is about the fundamentals. A couple of years ago I found myself somewhat rather by accident working on an embedded system written in C. There was a lot of code I considered to be too complex in the system but the head programmer, a pretty hardcore C hacker, was not really all that open to my ideas. Mostly he felt the code was fine. Gradually though I showed him some simple encapsulations that made the code a whole lot easier to understand and maintain. I recall he was kind of impressed after we looked at some code where I had moved bit field manipulations from being all over the place to living in a single function. He commented that yeah, the code was a lot simpler all of a sudden. My point is that this guy knew a lot more about C programming and embedded systems than I did, but I was still able to make a contribution precisely because my perspective was a bit different. I wasn't always thinking in terms that were so close to the bare metal. My lack of familiarity with bit fields forced me to simplify things so that this aspect of the code could live in just one place . Thus I wouldn't have to think about it all the time as I was working!
To sum up: I don't agree that "gurus" have to always be hardcore hackers. As long as they do have a reasonable amount of experience with real software development, I think the rest should be based on what you think of their ideas, not what they've done in the past. I know that there still are a lot of real con artists who just want to make a buck. There's not much you can do about that except to make the difference between them and the real thing clear in every project you work on...
@vladimir,
when I say "significant" software, I don't mean compilers or "bare metal" programming. (unless the "guru" in question is selling a new compiler writing methodology :-)).
That being said, look at the folks who promote "lean" or "agile" . Most of them (not all) haven't written *any* software in years , if not decades !! "Lean" and Scrum in particular are often driven top down by managers or "process consultant" types and not by developers.
I agree with most of what you say. But in your C example, you were able to *demonstrate* a difference (vs just making quasi religious claims - What if you could only talk the talk and not walk the walk?). This is exactly what I was talking about.
You also say
"If I were advising people who developed software in an area radically far away from mine, I would try to be humble and to make it clear that my ideas may not necessarily apply to their circumstances."
This is exactly my point. Most of the folks who go around "coaching" others in "agile processes" or whatever lack this quality of humility and introspection. And they also lack any experience of *any* significant software effort, even in the enterprise/business space.
So I think we mostly agree but with different points of emphasis.
PS: and don't worry about the chattiness. This helps me clarify and refine my thoughts.
Let me start with the "well, apart from Excel" comment. As David Pollak said, that's very like saying "...apart from pens". There's a whole world full of people who can (and do) write complicated programs with and in Excel. Now, the "programmers" of the world may or may not accept that these 'formulae' and/or 'scripts' are indeed programs, but let us, for the sake of compromise, say that these are at least 'proto-programs'. The issue I see, Ravi, is not that a majority of people in this world don't know programming. If you count the extraordinarily large numbers of people who get fairly complicated things accomplished using Excel, there is a very large number of 'programmers' in the world already.
The issue I see on a day to day basis is that the "programmers" who use 'languages' and 'compilers' and the whole shebang don't know how to communicate with people who use Excel. In fact, mostly, they don't think of the 'business types' as logical beings at all. The reverse, of course, is true as well. As someone who crosses this divide at least three times a day, in each direction, I find this extraordinary. It is also mostly a nuisance because I have to spend time 'translating' one language to the other.
So what is a good universal language? Do we teach all the Excel types to type a high level programming language instead? Do we teach the programmers to think of Excel as a program? I don't know the answers, but I do think a little bit of active listening from both groups would help tremendously. And maybe English will work after all :)
I'm just a passerby (who got here from reddit). The quality of discussion here is very high and I'm thoroughly enjoying myself.
+1 to Ravi and all the commenters. I wish I could articulate my thoughts half as well.
Post a Comment