 I first programmed a computer in 1972 - the computer was an ICL 2900 mainframe, we used the language Algol 68 and manually punched cards to actually program it. Program entry was so laborious and results turnaround so long that we did our utmost to make sure our programs would run correctly first time. We were responsible for everything from design to build and had deep personal experience of the high costs of design error.
During the early 1980s I noticed design become increasingly separated and isolated - coinciding with the rise of system centric rationalist waterfall thinking like SSADM (Structured Systems Analysis And Design Methodology) where higher level and higher paid systems analysts and designers would specify systems and pass the actual build to lower level and lower paid programmers.
Since the 1990s I noticed programming and coding become increasingly separated and isolated - coinciding with the rise of managerialism and its promotion of division, hierarchy, performance measurement and management where higher level and higher paid programmers would specify program logic and pass the actual build on to lower level and lower paid coders. It was in the 1990s that I first came across terms like lines of code per hour ... turning computer professionals into commodified assembly line code monkeys following instructions to assemble things against productivity targets as if they were writing pulp fiction.
What I used to know as programming has been fragmented - its been deconstructed and divided into notionally hierarchical specialisms.
Thinking generically about this: Design:
'Design is what links creativity and innovation. It shapes ideas to become practical and attractive propositions for users or customers. Design may be described as creativity deployed to a specific end.’ ~ George Cox
Design is about semantics, its interdisciplinary, multifaceted, synthetic and collaborative - designers work with people, things and systems about accomplish a task, solving a problem or a thing to be made or achieved.
Programming Programming is about creating the detailed logic and algorithms to solve a problem or make or achieve something ... its about creating a set of rules and sequences of actions that can be followed to accomplish a task, solve a problem or make or achieve something. Coding (or scripting) Coding is about writing instructions in a specific language to carry out a task. In terms of computers this means translating program logic into program code .... writing instructions for a computer in a language a computer can follow .. a computer programming language. In a sense design is about the why, programming about the how and coding about the what. Design, programming and coding - all of these are skilful and important. Good design blends in with what we do - a well designed product or program is "frictionless" - its not just easy to use but a pleasure to use. Good design is like "pushing against an open door - development can flow forward and progress relatively easily. Good programming is also well designed ... the algorithms of good programs can be described as elegant (if not beautiful) in the same way a mathematical formula might be described elegant as an efficient, effective and elegant solution. Good coding is also well designed and can be described as elegant (if not beautiful) in the same way that the language and structure used in a poem, story or song might be described as elegant and beautiful. I remember how Fortran programmers would struggle to express their code as efficiently and effectively as possible - showing great admiration for the elegance of other people's code just as if it were a formula. In the 1970s computer resources were very scarce and programmers had to take a lot of care to craft their code to fit into the limitations of computers at the time - remember that that Apollo missions to the moon used orders of magnitude less computer power than the average smartphone of today! Today I see all sorts of job types in what I used to know as "programming" ... "software engineer", software architect", "software developer" etc. I can see the logic of separating these according to circumstance and how people would prefer and be better at specialising in certain aspects. However, fragmentation in the role of programming is also driven by "politics" and can lead to significant problems. Managerialism seeks to entrench and centralise decision making and power by promoting hierarchy and division and centralising control through performance measurement and management. The result is fragmentation and polarisation - a small "elite" of high paid experts who manage and control a larger commodified pool of human resources - standardised replaceable parts in a "well oiled machine". This type of Fordist industrial mindset was problematic enough when applied to industrial processes and is equally problematic when applied to processes in the information age. This type of fragmentation is designed to centralise decision making, ownership and power so its not surprising to hear how people working in such fragmented operations abdicate involvement responsibility beyond their patch. I hear how programmers complain about how poor design passed down to them affects their work and how coders complain about how poor logic handed down to them affects their work. I hear about how quality control and testing of programs is carried out by specialist software testers who pass changes back to others in the chain - the original coder or programmer already working on something else so may never have to deal with "downstream" problems. I have to wonder how much of this is responsible for the amount of unreliable and insecure software we have seen since the 1980s.
The information age needs and will need a growing number of people with tech skills and this includes programming. Demand for IT skills is expected to grow at nearly five times the UK average over the next decade, digital tech skills have been added to Shortage Occupation Lists for UK and Scotland and a tech talent shortage is holding back business.
The response to the programmer skills shortage has been to think about it in the familiar industrial production efficiency framework of the last century that:
Aims to achieve maximum job fragmentation to minimize skill requirements and job learning time. Separates execution of work from work-planning ~ http://www.businessdictionary.com/definition/Taylorism.html The response to the programmer skills shortage has been to separate out design and programming skills and focus on coding - considered a lower skill and therefore quicker and easier to teach to produce an army of coders able to follow instructions to assemble code on production lines in the information age. Businesses ask Can ‘Coding Bootcamps’ Fix The Shortage of Engineers and our politicians ask Will compulsory coding in schools solve the UK's IT skills shortage with the view that ‘ If children are taught to code from an earlier age then this will only have a beneficial effect on the UK". Is the fragmentation of programming coding a design error? The 21st century response to the software skills shortage sounds rather like the 20th century response to the skills shortage - educate the masses to be able to follow orders with enough maths and english to follow orders and work on factory assembly lines. Is coding the production line job of the information age? BBC Bitesize for children says "you use code to tell a computer what to do. Before you write code you need an algorithm." When I learned to program the emphasis was on design rather than build. We spent a lot of time on logic and thinking through our programs and doing dry runs etc. Program entry and running took relatively little of our time. Today I notice a rush to code .. to almost make it up as you go along and spend so much more time with the code debugging it and running it over and over to get the bugs out. Is the rush to code producing pulp fiction - is it responsible for the rise in unreliable and insecure software we have all around these days that is never complete but always needs patching. We used to put reliability and security into the design - high modularisation and robust range and type checking on parameters at every stage. I often don't see robust parameter checking these days ... no wonder so many systems can be hacked using out of range values! Much of the routine deskilled and standardised work on industry production lines has now been automated - managerialism treated people like robots and now robots do much that work. Automated coding is embedded in our computer languages - high level programming languages are "translated" with compliers or interpreters into lower level machine languages and machine codes and it is these which computers actually use. It has been the ambition for as long as I remember that coding disappear and computers use natural human languages. We must consider the possibility that routine production line coding will like routine production line manufacturing become automated.  Much of coding education I see today is a sort of cut and paste recipe following activity - this not to be underestimated as it gives a real sense of satisfaction and achievement and can act as a great way into working with computers. Coding with tools designed for beginners like Scratch or App inventor is a playful introduction and first contact with programming but should be treated as just that ... a first contact with programming. Coding isn't all there is to programming - there is a whole lot more that is even better. Delving deeper into programming means getting creative, inventive and learning solve problems. Delving deeper into programming means learning how to design and to build - it means learning how to make and to craft. Programming is about problem solving, communication, creativity and invention. Teaching programming is an excellent way of teaching generic and transferable soft skills for jobs that don't even exist yet. Programs usually don't work first time and there is an iterative cycle of debugging them - trying out ideas, testing hypotheses, learning how to design things that are easier to support, maintain and develop. Teaching programming is an excellent way to teach people how to learn and how to adapt for an uncertain future - it need not be about working with computers at all. Coding is like baking something following a recipe - its a great introduction to cooking but do we want to stop there.  |
| "The Artisan Baker" .. http://shepherds.com.au/the-artisan-baker/ |
Coding is about learning a language but programming is about what you say.
A programmer designs and crafts things, a coder follows instructions and assembles things. We must ask ourselves what type of skills and education should pass on to future generations.
No comments:
Post a Comment