The following is the script for my podcast, which is discussed in my 30 March 2017 post.
(music)
(Narrator)
The hottest approach to software design today is called Agile software development. There are several competing brands. I, myself, am a Certified Scrum Master – a servant leader of a cross-functional development team. At its simplest, all Agile design methods require multiple 2- to 4-week development iterations during which software is written and tested. Ideally, developers will quickly know whether their work meets the needs of end users, because software users are key members of any Agile team.
The aspect of Agile development I want to focus on today is that tight feedback loop between end-user and software developer. It’s a key part of any Agile toolset, but it didn’t start with Agile development and probably should have been recognized as a best practice long ago.
Wikipedia lists 13 different Agile software development frameworks. [Wikipedia]
(various voices):
Discipline
Catalyst
Dynamic
Messy
Effective
Exciting
Learning-Oriented
Optimization
People-first
(Narrator):
While browsing through websites advertising Agile products, I found a lot of different words used to describe the techniques involved – tactical and strategic were two of the most powerful words. Several methods claimed superiority over others, although one method seemed quite humble – self-described as not best but merely sufficient. This was promoted as ideal really – you get just what you need, nothing extra that might get in the way. Just what is ‘sufficient.’
You might think, with all this hype that the general ideas behind Agile development are something new. While the writing of the Agile manifesto, the recognized birth of the Agile movement, certainly has a ground zero date (February 2001), the iterative approach to development was around at least at early as 1957, and the inclusion of end users during the design phase started as soon as software began to be written for end users.
Listen to this clip from “The Mother of All Demos” in 1968, as Doug Engelbart touches on the design approach his team employed while developing such ground-breaking innovations as the computer mouse and an interactive file server.
(Doug Engelbart)
“…and this item down here is the term boot-strapping applied in a slightly loose sense. We’re applying that to our approach. What we’re saying, we need a research subject group to give them these tools, put them to work with them, study them and improve them. Ah…ha…we’ll do that by making ourselves be the subject group and studying ourselves, and making the tools so that they improve our ability to develop and study these kinds of systems, and to produce in the end, this kind of system discipline.”
(Narrator)
That was the voice of the acclaimed computer visionary, Doug Engelbart. Did you catch what he was saying? They wanted to put research subjects to work using their tools, so they could study the tools themselves. It sounds like they weren’t 100% sure what could be done with their tools, yet. They needed users to interact with these things and figure out everything that could possibly be done with, for instance, links between and within files in a computer system. In terms of Affordance theory, Doug’s team did not know all the uses their tool suite afforded.
Their solution was to play with the tools themselves, and find ways to use the tools to make their work as developers easier. It’s interesting that the product being created, the computer software and toolset, was also the product that made the job of coding and creating easier.
As a software developer, I have mixed feelings about this approach. On the positive side, it would be difficult to find a tighter feedback loop. The end-user will immediately know if they have made their own job easier. The process affords instant feedback on the utility of a given bit of code. However, there is no knowing whether this bit of code will also make any other programmer’s job easier. When a new routine is used in a slightly different way, it might turn out to be disastrous. Having other people test the code affords new perspectives and tests that otherwise might not be thought of.
(musical interlude)
The earliest coders were always their own best customers. In the 1800s, Lady Lovelace wrote a great many routines for Charles Babbage’s Analytical Engine. They were never run, because the Analytical Engine, a great mechanical calculator, was never finished. [Gliek] Instead the routines served to further mathematical theory. This process of writing out mathematical formulas as a series of machine instructions forced mathematicians to think in very basic terms. The hypothetical Turing machine was imagined for just that purpose in 1936. [Gliek] When done as a purely intellectual activity, coding can be as simple as a sequence of operations written on paper, or even in one’s head.
Levy describes digital materials as being ‘schizophrenic,’ split into two parts, the visual representation on the one hand and the digital representation on the other – the ones and zeros stored on a bit of magnetic memory. If so software is split at least one degree further. There is the code that you see and can read. For most programming languages, that code must be passed through a compiler which builds an executable file. For some languages, the code is interpreted at runtime into machine language, so there is still a second layer of abstraction. Then at last the actual application runs, such as the program that is displaying the notes I’m reading right now.
Let’s explore this idea of programming as a thought process. According to Cortada, all of the basic concepts of programming were ‘uncovered’ in the 1940s and 1950s. He uses the word ‘uncovered,’ as if these concepts always existed, we had only to dig them up and dust them off. Put another way, by nature of the possible inputs and outputs, computers afforded various uses – computer programs – that may or may not have ever been written or even conceived.
(musical interlude)
(Narrator)
Programs that weren’t written in the pursuit of science were certainly written for people other than the author. In the 1960’s, computer applications were being packaged and marketed to businesses. [Cortada] In the 1980’s, the personal computer market would be flooded with software programs marketed to individuals. Companies began to manage software development projects as they would any other project, starting with a specification document, a development deadline, a testing phase and finally marketing to customers. This is a brief description of the Waterfall approach to software management and you can read all about in in the Project Management Book of Knowledge, or PMBOK, if you’d like. In any case, the market was hungry for new software and many companies fared very well using this approach.
Lu Luo wrote a research paper covering software testing techniques from 1975 through 2001. According to Luo, “The general aim of testing is to affirm the quality of software systems by systematically exercising the software in carefully controlled circumstances.” That doesn’t sound like an affordance approach to me.
I’m here with Deirdre Dibble, who has a lot of experience testing software used by colleges in New York State. Dierdre, can you describe for us your role in the software development process?
(Voice of Deirdre speaking)
(Narrator)
What is it that you do differently from, say, a programmer who is testing their own code?
(Voice of Deirdre speaking)
(Narrator)
How would you define the purpose of software testing?
(Voice of Deirdre speaking)
(Narrator)
Do you prefer to be involved in a project from the very beginning, possibly before any code has been written? Or do you think it’s just as useful to do most if not all your testing at the end of a project?
(Voice of Deirdre speaking)
(Narrator)
Thank you, Deirdre, for sharing your experience with us.
It can’t be coincidence that the Agile Manifesto was written in 2001, the same year that the Internet market crashed, the bursting of the ‘dot-com bubble.’ The old approach to software project management appeared to have failed. Following the PMBOK Guide afforded a lot of ways to track, control and quantify your software development process. What it didn’t afford was the flexibility to change your design when needed or a way to discover what software features your customer would actually use.
Agile project management, on other hand, proceeds on the assumption that not everything about the project is yet known. So, this process affords a high level of adaptability to a changing marketplace. Software testers are part of the development team, providing feedback throughout the process, not just at the end. This makes fixing mistakes easier, because you’ve caught them sooner. Small subsets of features are developed each iteration, with strict requirements for testing, so overall, the process affords a high level of quality. What it doesn’t afford is predictability. Managers are left hoping that the Agile team will deliver success faster than a traditional team, but they can’t put it on paper. Or, they aren’t supposed to.
It’s worth noting that Agile projects often fail, as do traditional Waterfall managed projects. But there is one thing, in my experience, that all successful projects have in common, that of a purposeful vision. For Agile projects, that vision comes from the designated ‘project owner.’ Without a strong project owner, who understands customer needs and refuses to accept a poor product, Agile teams are destined to spin aimlessly through their many iterations, going nowhere. Waterfall managed project teams, on the other hand, are at risk of grasping onto the wrong vision in the first place, and doggedly pursuing this goal to its bitter end, when a high-quality product that meets no one’s needs is fully tested and quickly shelved.
There is an even newer software development model – and some say it’s even better yet! The collaborative software development model is one in which all code is open source. Developers review and use each other’s code freely. Github.com boasts an estimated 19 Million developers collaborating and sharing code freely on the web. And Github provides free software management tools to them, some of the best change management tools available for code projects. (They also have a paid service, if you don’t want to share your code.) This is back to basics for programmers – writing code that serves their own interests, testing and sharing it. Not unlike the early days.
(music playing)
Thank you for joining me today. I’m Amy Pondolfino. It’s been my pleasure sharing these thoughts on software development management and the inter-changing roles of testers, users and programmers.
Many thanks to Thomas Aaron Pondolfino and Everett Pondolfino for sharing their voices.
Visit the Doug Engelbart Institute online for more about “The Mother of All Demos.”
Musical credits go to Thomas Aaron Pondofino and Everett Pondolfino.
(music)
(Narrator)
The hottest approach to software design today is called Agile software development. There are several competing brands. I, myself, am a Certified Scrum Master – a servant leader of a cross-functional development team. At its simplest, all Agile design methods require multiple 2- to 4-week development iterations during which software is written and tested. Ideally, developers will quickly know whether their work meets the needs of end users, because software users are key members of any Agile team.
The aspect of Agile development I want to focus on today is that tight feedback loop between end-user and software developer. It’s a key part of any Agile toolset, but it didn’t start with Agile development and probably should have been recognized as a best practice long ago.
Wikipedia lists 13 different Agile software development frameworks. [Wikipedia]
(various voices):
Discipline
Catalyst
Dynamic
Messy
Effective
Exciting
Learning-Oriented
Optimization
People-first
(Narrator):
While browsing through websites advertising Agile products, I found a lot of different words used to describe the techniques involved – tactical and strategic were two of the most powerful words. Several methods claimed superiority over others, although one method seemed quite humble – self-described as not best but merely sufficient. This was promoted as ideal really – you get just what you need, nothing extra that might get in the way. Just what is ‘sufficient.’
You might think, with all this hype that the general ideas behind Agile development are something new. While the writing of the Agile manifesto, the recognized birth of the Agile movement, certainly has a ground zero date (February 2001), the iterative approach to development was around at least at early as 1957, and the inclusion of end users during the design phase started as soon as software began to be written for end users.
Listen to this clip from “The Mother of All Demos” in 1968, as Doug Engelbart touches on the design approach his team employed while developing such ground-breaking innovations as the computer mouse and an interactive file server.
(Doug Engelbart)
“…and this item down here is the term boot-strapping applied in a slightly loose sense. We’re applying that to our approach. What we’re saying, we need a research subject group to give them these tools, put them to work with them, study them and improve them. Ah…ha…we’ll do that by making ourselves be the subject group and studying ourselves, and making the tools so that they improve our ability to develop and study these kinds of systems, and to produce in the end, this kind of system discipline.”
(Narrator)
That was the voice of the acclaimed computer visionary, Doug Engelbart. Did you catch what he was saying? They wanted to put research subjects to work using their tools, so they could study the tools themselves. It sounds like they weren’t 100% sure what could be done with their tools, yet. They needed users to interact with these things and figure out everything that could possibly be done with, for instance, links between and within files in a computer system. In terms of Affordance theory, Doug’s team did not know all the uses their tool suite afforded.
Their solution was to play with the tools themselves, and find ways to use the tools to make their work as developers easier. It’s interesting that the product being created, the computer software and toolset, was also the product that made the job of coding and creating easier.
As a software developer, I have mixed feelings about this approach. On the positive side, it would be difficult to find a tighter feedback loop. The end-user will immediately know if they have made their own job easier. The process affords instant feedback on the utility of a given bit of code. However, there is no knowing whether this bit of code will also make any other programmer’s job easier. When a new routine is used in a slightly different way, it might turn out to be disastrous. Having other people test the code affords new perspectives and tests that otherwise might not be thought of.
(musical interlude)
The earliest coders were always their own best customers. In the 1800s, Lady Lovelace wrote a great many routines for Charles Babbage’s Analytical Engine. They were never run, because the Analytical Engine, a great mechanical calculator, was never finished. [Gliek] Instead the routines served to further mathematical theory. This process of writing out mathematical formulas as a series of machine instructions forced mathematicians to think in very basic terms. The hypothetical Turing machine was imagined for just that purpose in 1936. [Gliek] When done as a purely intellectual activity, coding can be as simple as a sequence of operations written on paper, or even in one’s head.
Levy describes digital materials as being ‘schizophrenic,’ split into two parts, the visual representation on the one hand and the digital representation on the other – the ones and zeros stored on a bit of magnetic memory. If so software is split at least one degree further. There is the code that you see and can read. For most programming languages, that code must be passed through a compiler which builds an executable file. For some languages, the code is interpreted at runtime into machine language, so there is still a second layer of abstraction. Then at last the actual application runs, such as the program that is displaying the notes I’m reading right now.
Let’s explore this idea of programming as a thought process. According to Cortada, all of the basic concepts of programming were ‘uncovered’ in the 1940s and 1950s. He uses the word ‘uncovered,’ as if these concepts always existed, we had only to dig them up and dust them off. Put another way, by nature of the possible inputs and outputs, computers afforded various uses – computer programs – that may or may not have ever been written or even conceived.
(musical interlude)
(Narrator)
Programs that weren’t written in the pursuit of science were certainly written for people other than the author. In the 1960’s, computer applications were being packaged and marketed to businesses. [Cortada] In the 1980’s, the personal computer market would be flooded with software programs marketed to individuals. Companies began to manage software development projects as they would any other project, starting with a specification document, a development deadline, a testing phase and finally marketing to customers. This is a brief description of the Waterfall approach to software management and you can read all about in in the Project Management Book of Knowledge, or PMBOK, if you’d like. In any case, the market was hungry for new software and many companies fared very well using this approach.
Lu Luo wrote a research paper covering software testing techniques from 1975 through 2001. According to Luo, “The general aim of testing is to affirm the quality of software systems by systematically exercising the software in carefully controlled circumstances.” That doesn’t sound like an affordance approach to me.
I’m here with Deirdre Dibble, who has a lot of experience testing software used by colleges in New York State. Dierdre, can you describe for us your role in the software development process?
(Voice of Deirdre speaking)
(Narrator)
What is it that you do differently from, say, a programmer who is testing their own code?
(Voice of Deirdre speaking)
(Narrator)
How would you define the purpose of software testing?
(Voice of Deirdre speaking)
(Narrator)
Do you prefer to be involved in a project from the very beginning, possibly before any code has been written? Or do you think it’s just as useful to do most if not all your testing at the end of a project?
(Voice of Deirdre speaking)
(Narrator)
Thank you, Deirdre, for sharing your experience with us.
It can’t be coincidence that the Agile Manifesto was written in 2001, the same year that the Internet market crashed, the bursting of the ‘dot-com bubble.’ The old approach to software project management appeared to have failed. Following the PMBOK Guide afforded a lot of ways to track, control and quantify your software development process. What it didn’t afford was the flexibility to change your design when needed or a way to discover what software features your customer would actually use.
Agile project management, on other hand, proceeds on the assumption that not everything about the project is yet known. So, this process affords a high level of adaptability to a changing marketplace. Software testers are part of the development team, providing feedback throughout the process, not just at the end. This makes fixing mistakes easier, because you’ve caught them sooner. Small subsets of features are developed each iteration, with strict requirements for testing, so overall, the process affords a high level of quality. What it doesn’t afford is predictability. Managers are left hoping that the Agile team will deliver success faster than a traditional team, but they can’t put it on paper. Or, they aren’t supposed to.
It’s worth noting that Agile projects often fail, as do traditional Waterfall managed projects. But there is one thing, in my experience, that all successful projects have in common, that of a purposeful vision. For Agile projects, that vision comes from the designated ‘project owner.’ Without a strong project owner, who understands customer needs and refuses to accept a poor product, Agile teams are destined to spin aimlessly through their many iterations, going nowhere. Waterfall managed project teams, on the other hand, are at risk of grasping onto the wrong vision in the first place, and doggedly pursuing this goal to its bitter end, when a high-quality product that meets no one’s needs is fully tested and quickly shelved.
There is an even newer software development model – and some say it’s even better yet! The collaborative software development model is one in which all code is open source. Developers review and use each other’s code freely. Github.com boasts an estimated 19 Million developers collaborating and sharing code freely on the web. And Github provides free software management tools to them, some of the best change management tools available for code projects. (They also have a paid service, if you don’t want to share your code.) This is back to basics for programmers – writing code that serves their own interests, testing and sharing it. Not unlike the early days.
(music playing)
Thank you for joining me today. I’m Amy Pondolfino. It’s been my pleasure sharing these thoughts on software development management and the inter-changing roles of testers, users and programmers.
Many thanks to Thomas Aaron Pondolfino and Everett Pondolfino for sharing their voices.
Visit the Doug Engelbart Institute online for more about “The Mother of All Demos.”
Musical credits go to Thomas Aaron Pondofino and Everett Pondolfino.
Comments
Post a Comment