- Syracuse University (2011) Library Blog (link) and current state of their website (here)
- Mesh; an FP6 EU funded research and development project (link)
- The Social Travel App, another EU R&D project (link)
Monday, 12 October 2015
Examples of requirements
Interesting to see how much a design concept and/or existing context constrains the solution to a general need. Interesting to observe too how the site either confronts or avoids detailing that existing context in a substantive manner.
Managing Knowledge: It’s all in people’s heads!
"It’s all in people’s heads!"
Evidently knowledge is a crucial resource and one that it seems necessary to understand of itself and manage somehow. Theories of knowledge may therefore offer a way of getting to grips with how to manage it in teams or organisational settings. Epistemology is the study of theories of knowledge, of understanding how we know what we know, and further, of understanding how such knowledge is justified if at all.
Object Mediated Knowledge and Learning
The Russian psychologist Vygotsky (developmental psychology) considered all learning, or as he put it ‘development,’ to involve mediating interaction, transitional objects, before knowledge can be internalised. (Kaptelinin and Nardi, 2006) p48 The interaction between our ‘self’ and an object is, in a fundamental way, a physical experience. Different objects mediate the learning experience and knowledge in fundamentally different ways. For example a spreadsheet is not a direct substitute for a physically printed list of names. Our experience learning, using and working with both is different. This is not to say that one form is more useful than another, it is just very different. The phenomena we experience with a list on a wall chart are quite different to that when a list is presented in a spreadsheet or via slides. The quality of learning, knowledge and understanding will always be subtly different (not necessarily better or worse) depending on the objects and interactions we bring into the process of learning.
Figure: Zone of proximal development
Vygotsky’s theory of knowledge and learning mediated by objects was adapted in the 1980s and applied as a method for creating thoughtful and reflective descriptions of (dynamic) human activity systems. Activity Theory (AT) as it was termed is grounded in this theory of object-mediated learning, and it balances the view of a system as an ensemble of technical artifacts with the view that it is also a social construction. Simply put AT offers a balanced presentation of objects and tools, social structure (community, rules, division of labour), the role of the individual (subject); all with the goal of effecting change in the work; developing a new object to achieve some desired outcome.
"Software is developed or engineered, it is not manufactured in the classical sense"
(Pressman, 2000)
"Someone had to spend a hundred million to put that knowledge in my head. It didn’t come free."(Curtis et al., 1988)In an attempt to address the question of how to structure and organize high-tech development we needed to review assumptions surrounding the idea of systems. It is apparent that in spite of over decades of computer based development and innovation the development of high tech systems remains something of a mix of art and science. The question remains; how should we (as product or technology managers) go about fact-finding, specification, solution design, implementation and maintenance in the current era? Few social or organizational laws hold in all but the most general sense and even those laws are subject to change due to the flux of generations and capabilities in the technological environment. Opportunities are brief, specific skills and knowledge go out of date; markets and platforms rise and dominate quickly only to be overtaken by other newer systems.
Evidently knowledge is a crucial resource and one that it seems necessary to understand of itself and manage somehow. Theories of knowledge may therefore offer a way of getting to grips with how to manage it in teams or organisational settings. Epistemology is the study of theories of knowledge, of understanding how we know what we know, and further, of understanding how such knowledge is justified if at all.
Object Mediated Knowledge and Learning
The Russian psychologist Vygotsky (developmental psychology) considered all learning, or as he put it ‘development,’ to involve mediating interaction, transitional objects, before knowledge can be internalised. (Kaptelinin and Nardi, 2006) p48 The interaction between our ‘self’ and an object is, in a fundamental way, a physical experience. Different objects mediate the learning experience and knowledge in fundamentally different ways. For example a spreadsheet is not a direct substitute for a physically printed list of names. Our experience learning, using and working with both is different. This is not to say that one form is more useful than another, it is just very different. The phenomena we experience with a list on a wall chart are quite different to that when a list is presented in a spreadsheet or via slides. The quality of learning, knowledge and understanding will always be subtly different (not necessarily better or worse) depending on the objects and interactions we bring into the process of learning.
Figure: Zone of proximal development
Vygotsky’s theory of knowledge and learning mediated by objects was adapted in the 1980s and applied as a method for creating thoughtful and reflective descriptions of (dynamic) human activity systems. Activity Theory (AT) as it was termed is grounded in this theory of object-mediated learning, and it balances the view of a system as an ensemble of technical artifacts with the view that it is also a social construction. Simply put AT offers a balanced presentation of objects and tools, social structure (community, rules, division of labour), the role of the individual (subject); all with the goal of effecting change in the work; developing a new object to achieve some desired outcome.
Managing development; what really happens
Even as systems development processes have expanded to include ‘human factors’ through participative design or user centred approaches (Bannon, 1998, Ehn, 1990) they barely acknowledge or recognize the practical accomplishment of the systems development process itself as a social and cooperative work form (Mackenzie, 2005, Ó Riain, 2000). While designers are involved in making others’ behind the scenes work available, to intervene with well-designed software, their own design interactions are relatively poorly understood.
What is it that distinguishes the practice of software systems development from other creative professions? Is the act and process of producing software distinctive from other forms of production? In a recent sample of 28 software producing or servicing firms in Ireland covered organisations ranging from 20 individuals to thousands (companies ranged over SMEs to government agencies and multi-national corporations), team sizes ranged from 3 to around 30 (typically from 5 to 10) and software codebase size ranged from 100k to several millions of LOC (see below).
Table: Product size versus team size; Ireland, 2010 (Higgins et al, unpublished).
To put this in context; consider an academic research conference with around 100 papers being presented. Each paper consisting of approximately 6,000 words, equating to perhaps 800 lines of text mapping down to about 600 sentences or fact statements. Let us assume that the knowledge content of the collected conference proceedings is roughly 100 papers x 600 fact statements per paper; equating to 60,000 lines of code equivalent. Contrast this with a fairly typical team of software engineers of anywhere from 5 to 30 people managing the active compilation and on-going design of a software product of 100K LOC. This is the software equivalent of somewhere between 150 to 200 conference papers. Basically, small software development teams are involved in a collective intellectual exercise commensurate with the output of 150+ academic researchers.
To put it in another context, have a look at the graph of codebase size visualisation informationisbeautiful.net. Interestingly codebase sizes begin to approach the numbers of lines of decoded gene DNA in organisms...
What developers actually do
In practice developers find themselves working within fractal problem solving loops, in which you may work on all levels; from developer the 'whole program level' right the way through to the 'one line of code' level. Developers use all their skills at all times throughout the project, skills encompassing requirements analysis, design, coding and maintenance.
Raccoon describes the process as essentially a focus on lines of code, on interpreting and problem solving. His insight is that the work of development revolves around problem solving centred on code and data. The 'line of code' means actual software code but can include a requirements statement or project tasks. As each ‘line of code’ changes its impact propagates from one end to another of a project. This brings attention back to the end-to-end nature of design and code and what it addresses. There is a continuum from technical foundations (code, architectures, frameworks, 3rd party tools) through to user visible screens and performance. Its consequence is to highlight the necessity for users, developers and technology to converge and agree for any status quo to be achieved or reach. The other consequence is that any status quo is simply an intermediate point, one of many status quos (see below).
Figure: Relationships between risk/stability activities (adapted from Raccoon, 1995)
A consequence of the Raccoon's analysis is to claim that traditional ideas about the connections between phases of a lifecycle like waterfall or spiral are not true depictions of the state of a project (see below). He provides four life cycle archetypes ranging over the 'simple but rigid' to 'complex but adaptable'. The waterfall or SDLC are termed sequential; modified waterfall is overlapping; spiral is lingering; chaotic is all-at-once or code-and-fix.
Figure: Four life cycle archetypes; the relationships between analysis, design, implementation and maintenance (from Raccoon, 1995)
Most lifecycles are simplifications of the real-world situation, although they may not acknowledge this as such, however the truth is that real development projects are complex, messy and unstable. It turns out that the very act of programming is in fact a signature or leitmotif for the whole process of developing software (Raccoon, 1995). While this is very much a developer’s view of development projects rather than a user’s or managers, the perspective aims to give a more truthful description of their roles too.
What is it that distinguishes the practice of software systems development from other creative professions? Is the act and process of producing software distinctive from other forms of production? In a recent sample of 28 software producing or servicing firms in Ireland covered organisations ranging from 20 individuals to thousands (companies ranged over SMEs to government agencies and multi-national corporations), team sizes ranged from 3 to around 30 (typically from 5 to 10) and software codebase size ranged from 100k to several millions of LOC (see below).
Table: Product size versus team size; Ireland, 2010 (Higgins et al, unpublished).
To put this in context; consider an academic research conference with around 100 papers being presented. Each paper consisting of approximately 6,000 words, equating to perhaps 800 lines of text mapping down to about 600 sentences or fact statements. Let us assume that the knowledge content of the collected conference proceedings is roughly 100 papers x 600 fact statements per paper; equating to 60,000 lines of code equivalent. Contrast this with a fairly typical team of software engineers of anywhere from 5 to 30 people managing the active compilation and on-going design of a software product of 100K LOC. This is the software equivalent of somewhere between 150 to 200 conference papers. Basically, small software development teams are involved in a collective intellectual exercise commensurate with the output of 150+ academic researchers.
To put it in another context, have a look at the graph of codebase size visualisation informationisbeautiful.net. Interestingly codebase sizes begin to approach the numbers of lines of decoded gene DNA in organisms...
What developers actually do
"Developers solve problems at all levels between the ‘whole project’ level and the ‘one line of code’ level... we break complex problems into simpler sub problems. We use this reductionist approach to deal with problems that are too large to handle otherwise."Raccoon proposes a simple cycle of problem definition, development, solution and stability as a motif for the entire business of producing software (below). Status quos can be thought of as known stable points, perhaps something that compiles without errors while also implementing some subset of what is eventually required. He posits that the activities of the problem solving loop actually shape the large-scale structure of development work, regardless of what the espoused methodology or lifecycle is. This based on a constitutive connection between “one line of code and the entire project” (Raccoon, 1995). Raccoon argues for the analogical use of Chaos theory as an underlying theory for systems development projects; simple self-similar processes giving rise to complex emergent behaviour.
(Raccoon, 1995)
In practice developers find themselves working within fractal problem solving loops, in which you may work on all levels; from developer the 'whole program level' right the way through to the 'one line of code' level. Developers use all their skills at all times throughout the project, skills encompassing requirements analysis, design, coding and maintenance.
Raccoon describes the process as essentially a focus on lines of code, on interpreting and problem solving. His insight is that the work of development revolves around problem solving centred on code and data. The 'line of code' means actual software code but can include a requirements statement or project tasks. As each ‘line of code’ changes its impact propagates from one end to another of a project. This brings attention back to the end-to-end nature of design and code and what it addresses. There is a continuum from technical foundations (code, architectures, frameworks, 3rd party tools) through to user visible screens and performance. Its consequence is to highlight the necessity for users, developers and technology to converge and agree for any status quo to be achieved or reach. The other consequence is that any status quo is simply an intermediate point, one of many status quos (see below).
Figure: Relationships between risk/stability activities (adapted from Raccoon, 1995)
A consequence of the Raccoon's analysis is to claim that traditional ideas about the connections between phases of a lifecycle like waterfall or spiral are not true depictions of the state of a project (see below). He provides four life cycle archetypes ranging over the 'simple but rigid' to 'complex but adaptable'. The waterfall or SDLC are termed sequential; modified waterfall is overlapping; spiral is lingering; chaotic is all-at-once or code-and-fix.
Figure: Four life cycle archetypes; the relationships between analysis, design, implementation and maintenance (from Raccoon, 1995)
"Developers interleave design, implementation and testing as they work on different pieces of the project. It is not possible to isolate these phases from each other…each phase involves setting goals, carrying out the goals, and maintaining the results."He concludes that life cycles are just our own perspectives “on the state of a project rather than any essential truth about the state of the project” (Raccoon, 1995) The basic problem solving loop (Figure 7) is self evident but it is also intended to apply to the activities at the whole program level, component level, function level and ‘one line of code level.’ Raccoon sees this as an intrinsic process happening regardless of the lifecycle phase we consider the project to be in at any time. The same basic learning loop applies also during the analysis and requirements phase, design phase, implementation phase, and maintenance. Indeed ‘phase means perspective,’ it is not a predetermined state.
(Raccoon, 1995)
Most lifecycles are simplifications of the real-world situation, although they may not acknowledge this as such, however the truth is that real development projects are complex, messy and unstable. It turns out that the very act of programming is in fact a signature or leitmotif for the whole process of developing software (Raccoon, 1995). While this is very much a developer’s view of development projects rather than a user’s or managers, the perspective aims to give a more truthful description of their roles too.
Are methods necessary?
How does systems analysis and design of software take place in practice? What is the role if any of methodologies in the organisation of development? The authors argue that
The structures of organisation arise through experiences that solidify into practices over time.
REFERENCES
Guindon, R. (1990) Designing the Design Process: Exploiting Opportunistic Thoughts. Human-Computer Interaction, 5, 305-344.
Nandhakumar, J. & Avison, D. E. (1999) The fiction of methodological development: a field study of information systems development. Information Technology & People, 12, 176-186.
"traditional IS development methodologies are treated primarily as a necessary fiction to present an image of control or to provide a symbolic status, and are too mechanistic to be of much use in the detailed, day-to-day organization of systems developers' activities." (Nandhakumar & Avison, 1999)
The structures of organisation arise through experiences that solidify into practices over time.
"ad hoc development practices became institutionalized, forming structural properties of the team. The team members were therefore following these practices reflexively in their day-to-day activities." (Nandhakumar & Avison, 1999: 182)The structure of methodologies is shown to be demonstrably broken across time, in the same way that the structure of life cycles have been shown to be fictions, not apparent in fact (Guindon, 1990). But if methods and life cycles are known to be fictions why are they employed? Are methods necessary and if so who uses them and why?
REFERENCES
Guindon, R. (1990) Designing the Design Process: Exploiting Opportunistic Thoughts. Human-Computer Interaction, 5, 305-344.
Nandhakumar, J. & Avison, D. E. (1999) The fiction of methodological development: a field study of information systems development. Information Technology & People, 12, 176-186.
Friday, 9 October 2015
Mapping the maze...
Is this structure an intrinsically impractical building? You might consider the heart of University College Dublin's central campus, the so-called UCD Newman Joyce Precinct, to be Ireland's own minor example of architecture that drives its users mad.
Would you like to experience what if feels like to be a lab rat in a maze? Try navigating through the Newman building's maze-like identical internal corridors, with orthogonal carbon copy junctions and stairwells, and no view of the outside world. Any building that has trackways marking its interior is a clear indication that the architects have failed to design for human (humane?) use. The corridors of the Newman are painted with colour coded tracks starting from an obscure services dock on the first floor. These coloured lines snake through the complex to ambiguous destinations like 'section EH'. The Joyce Library is no better.
That said, I have a grudging respect and possibly admiration for the structure and its designers for demonstrating that objects like this may exert agency and confound us. To such effect that even brilliant academics get lost. Is reminds me that the physical corporeal world can still kick back at us humans.
Wednesday, 7 October 2015
Disproving the Mythical Man-Month With DevOps?
In the article "What CIOs need to know about microservices and DevOps" Carla Rudder interviewing Anders Wallgren (link) on the topic of so-called 'micro-services', Wallgren states...
Mature organisations have development environments that tend to an ideal arrangement, i.e. regular (daily/weekly) stable builds with customer releases occurring quarterly or less frequently. Much of the open source world achieves this level of responsivity, a flexible a mix of iterative/agile + staged releases. However, release/releasability is not the same as being able to scale ramping of new feature development.
Note:
Ref. for counter-arguments see the balanced and sane (for Slashdot) discussion on Slashdot (link)
"you can actually start to beat the Mythical Man-Month (i.e. the long-standing theory that adding people to a project lowers, rather than increases, velocity)."Hmmm, with 'micro-services' I presume he is presenting software system architecture made up of atomic independent elements? How tenable is that argument, really? Is it widely applicable or even achievable in reality? And what, if anything, is the significance of DevOps specialism, processes, operations, to his claim and assertion? Isn't DevOps culture and attitude about uptime, stability, scaleable secure deployments? Should DevOps be the place for the white heat of creative design and development?
Mature organisations have development environments that tend to an ideal arrangement, i.e. regular (daily/weekly) stable builds with customer releases occurring quarterly or less frequently. Much of the open source world achieves this level of responsivity, a flexible a mix of iterative/agile + staged releases. However, release/releasability is not the same as being able to scale ramping of new feature development.
Note:
Ref. for counter-arguments see the balanced and sane (for Slashdot) discussion on Slashdot (link)
Sunday, 4 October 2015
Life Cycle Concept
A review of the origin and evolution of the lifecycle concept as applied to software engineering. Pointing out the proliferation and diversity of life cycles and methods addressing high-tech systems development.
For the purpose of the following discussion I focus on life cycles as a subset of management systems for development and so propose the following definition: a life cycle is a process that describes how to start and finish a high-tech project. Applying this definition, an organization may employ different life cycles for different projects. Life cycles simply provide local guidance on how to organize a development project team and (should) generally steer clear of prescribing the operational structure of the wider organization.
LIFE CYCLE MODELS IN SYSTEMS DEVELOPMENT
The life cycle concept is much used (perhaps overused) and maligned in the informatics discipline; assuming informatics to encompass Information Systems, Computer Science, Software Engineering, programming, and computing more generally. The Systems Development Life Cycle has been described as harmful because it is a blinkered (though comforting) world-view that imposes a project management structure on system development (McCracken and Jackson, 1982). Furthermore there are a number of common and well known circumstances in which a unified staged development cycle (SDLC) is known to fail. In these situations alternate approaches like mock-ups, rapid prototypes, and end-user development are indicated (Gladden, 1982, McCracken and Jackson, 1982).
In 1991 Peter DeGrace and Leslie Stahl created an inventory of the life cycles and software engineering methods in use. Fully half of all approaches were waterfall model in one guise or another, consequently they spent half of their time critiquing waterfall (DeGrace and Stahl, 1991). But what are we talking about when we use the ‘life cycle’ term? The following table (below) summarizes DeGrace & Stahl and complements their catalogue by including more recent inventories of software engineering management/design concepts. These concepts are variously labeled as life cycles, methodologies, design methods, models, even systems themselves.
Table: Life cycles and development methods
DeGrace & Stahl (1991), McConnell (1996) and Avison & Fiztgerald (2006) provide detailed descriptions of the life cycles or methodologies they document. Boehm’s (2006) presentation summarizes the historical development of software engineering and possibilities for computer technology and its management into the 21st Century. We may make some generalizations based on this overview.
Over the 25 years represented by these snapshots the number of life cycles and methods has steadily increased. It is not immediately obvious whether one or other approach is simply a life cycle, or a design method, or if indeed is intended for wider application for governing organizational operations. Boehm characterized life cycles into four categories (Boehm, 1988):
Wider operational structures are of course necessary but would instead be the focus of what we might term management ‘frameworks’ and general organizational theory (see following section). A life cycle is therefore an organizational template for managing a project and will therefore be largely concerned with addressing issues affecting scope, cost/effort, time and quality.
A further distinction is necessary to help us reduce confusion among this variety of life cycles, methods and methodologies. Life cycle should not become conflated with design method. Design methods are many and various, and sometimes mandate wider organizational structures and events, but they are ultimately techniques for ‘representing’ and manipulating design objects or a particular technology itself. For example, design methods are may be closely linked to a particular software tool or programming paradigm e.g. Z and Formal specification, functional design and structured programming, ERD and data flow with DBMS design, UML and OOAD etc. (Bell, 2000).
THE WATERFALL MODEL (AKA SDLC)
Table: Development life cycles in firms; Ireland 2010 (Higgins et al, unpublished)
One of the earliest descriptions of the waterfall method for software development is often attributed Winston W. Royce’s in his article “Managing the Development of Large Software Systems” (Royce, 1970). Royce drew on his own experience working as a programmer on early high-tech Department of Defense projects in the 1960s. He described the difficulties of achieving success in terms of operational state (functionality), on time, and within costs. Royce’s goal was to improve our capability to program large-scale developments, to better produce and deliver, from concept through to implementation, large computer systems. Royce presented a detailed description of the SDLC’s step-wise model for development, which he dismisses as infeasible. He terms these kinds of systems the 'grandiose approach' to software development but concluded that the grandiose approach is an "intrinsically risky development process."
Figure: A sketch of the SDLC; The Grandiose Approach (from Royce, 1970)
Figure: The essential activities of software development (from Royce, 1970)
Royce identified the central challenge for large computer systems in dealing with the essential character of computing, the so-called 'essence of programming.' The work of software development centers on two main activities; analysis and coding. No other activities contribute as directly to the final product. These activities together "involve genuinely creative work which directly contributes to the final product." (Royce, 1970) However as a project becomes sufficiently large it becomes necessary to revert to the grandiose model to formally highlight other necessary activities. But the central problem with the grandiose model is that task and leakage inevitably takes place between successive process steps. Task leakage and linkage (see below) occurs complexly between all steps in the process, from the very last stage right back into the earliest. The central problem is that 'design' involves everything; analysis, coding, testing, how the product is used etc. Furthermore he claims it is futile to treat the high-tech development process as a linear flow. Simply put, a linear process model breaks down for anything other than the most trivial commodity task.
Figure: Task leakage and unexpected linkage complicates the SDLC on real systems development projects (from Royce, 1970).
In the absence of an alternative to the development lifecycle Royce identified additional necessary steps to ensure large scale software systems satisfy requirements, to ensure they are stable, usable, maintainable etc. Leakage in the development lifecycle should be dealt with explicitly through additional activities (below) rather than by hiding them “under the rug” (Brooks Jr., 1995).
Figure: Remedies to the SDLC (adapted from Royce, 1970)
Royce's Remedies
These ideas presage Fred Brooks’ (Brooks Jr., 1995) own conclusions from working on the IBM System/360 and OS/360 development project. The principles also hint at what is now labeled Agile Development (see following section). They were a radical departure from centrally planned approaches of the day where analysts worked apart from designers who kept aloof from programmers and users or customers were almost entirely absent from development projects (some might argue the same conditions still hold in many organizations).
Royce was conscious that development life cycles can become a self defeating remedy to the challenge of managing high-tech projects; the cure may be worse than the disease. The extra steps and activities of the development life cycle drive up the cost and complexity of managing the development of a large system. Additional management activity further complicates systems projects and potentially drives down the probability of success while at the same time driving up cost. This introduces its own problems as customers may be reluctant to pay for the cost and complexity of additional management, and designers are often reluctant go along with the demands imposed by additional management activities all of which pull time away from software design and development. Royce concludes therefore that…
“The prime function of management is to sell these concepts to both groups and then enforce compliance on the part of development personnel.” (Royce, 1970)
A SPIRAL MODEL OF SOFTWARE DEVELOPMENT AND ENHANCEMENT
The spiral model was presented in 1988 as a general life cycle model (Boehm, 1988). Lifecycles, or to use Boehm’s label ‘software process models,’ define the order of events and activities for software development projects. The spiral model he proposed was an attempt to address the deficiencies of linear stage-wise development models. The spiral was presented as a unified life cycle model, generally useful in so far as it specifies the all necessary activities and transformations experienced over the life of a software development project. Boehm introduced the idea that a development life cycle could be designed as a process for managing risk rather than introducing risk. The spiral redefined software development as a process (below) and popularized the notion that development could be considered an on-going cycle of iterations rather than an end-to-end production line. The spiral process allows for requirements to evolve and for the project to account for its own changing environment.
Figure: Spiral model of the software process (adapted from Boehm, 1988)
Delivery of a version of the evolving project is a key milestone for each cycle. The project is reviewed and could potentially be stopped at the end of each cycle of the spiral. Each review event commits the project to further exploration and taking on additional risk, which is clarified and resolved in prototypes and simulations. Working prototypes or partial versions of the product are then produced and validated. Turns through the spiral expand progressively to include more and more of the waterfall’s activities (design, code, test, implementation, operations). The spiral can be used to manage small incremental project improvements or large uncertain product development projects.
A way of understanding the relationship between a development project’s cost, completion and risk is depicted (see below). The expanding circles reflect the cumulative cost of the project; the phase or % completion of each cycle is evident by progress along each cycle or turn. Risk and its trend (increasing or decreasing) are represented as a vector from the project origin (which shifts) to the current point in the cycle.
Figure: Spiral model 'risk, completion, cost disk'
The idea of ‘design risk’ reduces to being a factor of the people involved in a project. A low risk design element for an experienced engineer may be a challenging and risky job for an inexperience engineer. However managing the risk by reverting to the experienced engineer may be a short-term solution to what is in fact a different game running over the long term. Involving customers and users in prototype evaluation is a way of exploring requirements and further reducing risk.
By championing prototyping Boehm also provided a place for Royce’s advice to plan to ‘do it twice’ (Royce, 1970), i.e. a preliminary design and implementation that exercises all the other stages of the lifecycle. A development project undergoes a series of iterations or rounds; proceeding to the next round depends on how the preceding round went and on continuing viability of the business case driving the project.
Boehm’s spiral was the last significant theoretically driven contribution to high-tech project management up until 1999. Subsequent contributions to the burgeoning business of creating new life cycles and development methodologies were either hybrids of spiral/waterfall or techniques rather than whole project life cycles. For example Rapid Application Development (RAD) was founded on a single big idea, working prototypes. Iterative development is conceptually equivalent to spiral. Dynamic Systems Development Methodology (DSDM) was designed around the key concept of iterations. Participatory design, user driven development and Joint Application Development (JAD) give emphasis to user/customer engagement in the development process. The Rational Unified Process (RUP) gave credence to the manageability of large sets of projects and popularized the idea of automatic code generation from UML designs.
The break Boehm makes with the thinking of the day was to present a concrete actionable model for organizations to shift systems development from a batch thinking to process thinking perspective. That development was more like a process than assembly, where assembly lines move a product-in-progress from stage to stage to completion. The spiral model characterized development as an on-going cycle of expanding requirements (and risk) followed by resolving the requirement (removing risk) by creating new parts. An initially uncertain product idea gradually comes into focus over repeated cycles in an on-going process of discovery and refinement.
The process view of product development encompasses the batch view as each cycle can be considered a small batch.
CONCLUSIONS
New technologies in the form of better programming languages, more powerful computing hardware, new languages and development environments have held out the promise of improved production cycles for software and high-tech development. Unfortunately technological remedies are slow to evolve or when developed result in pushing the problem of design into other zones of the development ecosystem.
While the life cycle metaphor is certainly a useful way of characterising development activities and helps order or structure the working environment practitioners assert that the microscopic activities of programming are intrinsically bound up with each other and cannot be meaningfully separated. Cyclic or iterative process models like spiral are certainly better approximations of the underlying process of software design and production, and are therefore an improvement on earlier models. But at a macroscopic level, the level of teams and projects and organizations, stage-wise, and even cyclic process models like spiral simply do not capture the practical reality of programming. Ultimately life cycle models are mere organizational constructs, ways of ordering projects; they do not address the detailed production of systems design.
We have noted that stage-wise development models like the SDLC and waterfall become unmanageable for well-understood reasons:
"Life is the state of ceaseless change and functional activity peculiar to organized matter."The terms ‘development cycle’ and ‘life cycle,’ are synonymous in engineering and have been in common use in the fields of computing and software since the 1960s. From the early 1900s it is used next in sociology applied to the individual’s life history and is then applied to businesses and manufactured products from the 1950s onwards (OED, 2010). The earliest references to ‘life cycle’ use it to refer to the entirety of a biological life described scientifically. The life cycle describes an entire biological life (birth, maturation, death) as an abstract sequence of events and transformations. The idea of a ‘life cycle’ is a relatively modern concept. Its published use commences in the mid 1800s when the idea of ‘cycles’ with connotations of lunar, diurnal, mechanical, of recurring events and events recurring in a chronological cycle. Implicit within the definition of a life is the idea of a beginning and an ending, birth and death, the span of a life, or in the case of technology, the duration of a project or product. Ultimately the idea of life cycle is a metaphorical description of projects applied over relatively long durations. It links the idea of activity with the passage of time but emphasising the long term processes under which activities become transformed into the cohering thing that projects produce, be they a business model, a technology, a business process, service etc.
(Fowler and Fowler, 1929)
For the purpose of the following discussion I focus on life cycles as a subset of management systems for development and so propose the following definition: a life cycle is a process that describes how to start and finish a high-tech project. Applying this definition, an organization may employ different life cycles for different projects. Life cycles simply provide local guidance on how to organize a development project team and (should) generally steer clear of prescribing the operational structure of the wider organization.
LIFE CYCLE MODELS IN SYSTEMS DEVELOPMENT
The life cycle concept is much used (perhaps overused) and maligned in the informatics discipline; assuming informatics to encompass Information Systems, Computer Science, Software Engineering, programming, and computing more generally. The Systems Development Life Cycle has been described as harmful because it is a blinkered (though comforting) world-view that imposes a project management structure on system development (McCracken and Jackson, 1982). Furthermore there are a number of common and well known circumstances in which a unified staged development cycle (SDLC) is known to fail. In these situations alternate approaches like mock-ups, rapid prototypes, and end-user development are indicated (Gladden, 1982, McCracken and Jackson, 1982).
In 1991 Peter DeGrace and Leslie Stahl created an inventory of the life cycles and software engineering methods in use. Fully half of all approaches were waterfall model in one guise or another, consequently they spent half of their time critiquing waterfall (DeGrace and Stahl, 1991). But what are we talking about when we use the ‘life cycle’ term? The following table (below) summarizes DeGrace & Stahl and complements their catalogue by including more recent inventories of software engineering management/design concepts. These concepts are variously labeled as life cycles, methodologies, design methods, models, even systems themselves.
Table: Life cycles and development methods
DeGrace & Stahl (1991), McConnell (1996) and Avison & Fiztgerald (2006) provide detailed descriptions of the life cycles or methodologies they document. Boehm’s (2006) presentation summarizes the historical development of software engineering and possibilities for computer technology and its management into the 21st Century. We may make some generalizations based on this overview.
Over the 25 years represented by these snapshots the number of life cycles and methods has steadily increased. It is not immediately obvious whether one or other approach is simply a life cycle, or a design method, or if indeed is intended for wider application for governing organizational operations. Boehm characterized life cycles into four categories (Boehm, 1988):
- Code and Fix
- Stagewise and Waterfall Models
- Transform Model (4GLs, code generators, very high level)
- The Spiral Model
Wider operational structures are of course necessary but would instead be the focus of what we might term management ‘frameworks’ and general organizational theory (see following section). A life cycle is therefore an organizational template for managing a project and will therefore be largely concerned with addressing issues affecting scope, cost/effort, time and quality.
A further distinction is necessary to help us reduce confusion among this variety of life cycles, methods and methodologies. Life cycle should not become conflated with design method. Design methods are many and various, and sometimes mandate wider organizational structures and events, but they are ultimately techniques for ‘representing’ and manipulating design objects or a particular technology itself. For example, design methods are may be closely linked to a particular software tool or programming paradigm e.g. Z and Formal specification, functional design and structured programming, ERD and data flow with DBMS design, UML and OOAD etc. (Bell, 2000).
THE WATERFALL MODEL (AKA SDLC)
"If the only model we have is the waterfall, then we will see the world in terms of problems that can be solved using it. Our world and our field are richer than that. We need a toolbox of models." (DeGrace and Stahl, 1991)Waterfall theories of system development still abound so we should investigate their origin and definition. The peculiar thing is the death of waterfall was heralded years ago but the idea persists (Hanna, 1995, Gladden, 1982, McCracken and Jackson, 1982). Waterfall thinking was (and perhaps still is) entrenched in industry and general thinking. In spite of numerous critiques the waterfall is still with us (Table 2). The waterfall has become an almost subconscious assumption in management, with the risk that this subliminal view of high-tech projects shapes our world-view of production and innovation more generally.
Table: Development life cycles in firms; Ireland 2010 (Higgins et al, unpublished)
One of the earliest descriptions of the waterfall method for software development is often attributed Winston W. Royce’s in his article “Managing the Development of Large Software Systems” (Royce, 1970). Royce drew on his own experience working as a programmer on early high-tech Department of Defense projects in the 1960s. He described the difficulties of achieving success in terms of operational state (functionality), on time, and within costs. Royce’s goal was to improve our capability to program large-scale developments, to better produce and deliver, from concept through to implementation, large computer systems. Royce presented a detailed description of the SDLC’s step-wise model for development, which he dismisses as infeasible. He terms these kinds of systems the 'grandiose approach' to software development but concluded that the grandiose approach is an "intrinsically risky development process."
Figure: A sketch of the SDLC; The Grandiose Approach (from Royce, 1970)
Figure: The essential activities of software development (from Royce, 1970)
Royce identified the central challenge for large computer systems in dealing with the essential character of computing, the so-called 'essence of programming.' The work of software development centers on two main activities; analysis and coding. No other activities contribute as directly to the final product. These activities together "involve genuinely creative work which directly contributes to the final product." (Royce, 1970) However as a project becomes sufficiently large it becomes necessary to revert to the grandiose model to formally highlight other necessary activities. But the central problem with the grandiose model is that task and leakage inevitably takes place between successive process steps. Task leakage and linkage (see below) occurs complexly between all steps in the process, from the very last stage right back into the earliest. The central problem is that 'design' involves everything; analysis, coding, testing, how the product is used etc. Furthermore he claims it is futile to treat the high-tech development process as a linear flow. Simply put, a linear process model breaks down for anything other than the most trivial commodity task.
Figure: Task leakage and unexpected linkage complicates the SDLC on real systems development projects (from Royce, 1970).
In the absence of an alternative to the development lifecycle Royce identified additional necessary steps to ensure large scale software systems satisfy requirements, to ensure they are stable, usable, maintainable etc. Leakage in the development lifecycle should be dealt with explicitly through additional activities (below) rather than by hiding them “under the rug” (Brooks Jr., 1995).
Figure: Remedies to the SDLC (adapted from Royce, 1970)
Royce's Remedies
"Begin the design process with program designers, not analysts or programmers [so that] preliminary program design is complete before analysis begins"Royce proposed 5 steps to overcome the shortcomings of the development lifecycle. The alternative is in fact an iterative interactive approach, albeit described in the terms of the grandiose development lifecycle. System design is reduced to five tenets or principles for minimizing development risk:
(Royce, 1970)
- Program design comes first
- Document the design
- Do it twice
- Plan, control and monitor testing
- Involve the customer.
These ideas presage Fred Brooks’ (Brooks Jr., 1995) own conclusions from working on the IBM System/360 and OS/360 development project. The principles also hint at what is now labeled Agile Development (see following section). They were a radical departure from centrally planned approaches of the day where analysts worked apart from designers who kept aloof from programmers and users or customers were almost entirely absent from development projects (some might argue the same conditions still hold in many organizations).
Royce was conscious that development life cycles can become a self defeating remedy to the challenge of managing high-tech projects; the cure may be worse than the disease. The extra steps and activities of the development life cycle drive up the cost and complexity of managing the development of a large system. Additional management activity further complicates systems projects and potentially drives down the probability of success while at the same time driving up cost. This introduces its own problems as customers may be reluctant to pay for the cost and complexity of additional management, and designers are often reluctant go along with the demands imposed by additional management activities all of which pull time away from software design and development. Royce concludes therefore that…
“The prime function of management is to sell these concepts to both groups and then enforce compliance on the part of development personnel.” (Royce, 1970)
A SPIRAL MODEL OF SOFTWARE DEVELOPMENT AND ENHANCEMENT
The spiral model was presented in 1988 as a general life cycle model (Boehm, 1988). Lifecycles, or to use Boehm’s label ‘software process models,’ define the order of events and activities for software development projects. The spiral model he proposed was an attempt to address the deficiencies of linear stage-wise development models. The spiral was presented as a unified life cycle model, generally useful in so far as it specifies the all necessary activities and transformations experienced over the life of a software development project. Boehm introduced the idea that a development life cycle could be designed as a process for managing risk rather than introducing risk. The spiral redefined software development as a process (below) and popularized the notion that development could be considered an on-going cycle of iterations rather than an end-to-end production line. The spiral process allows for requirements to evolve and for the project to account for its own changing environment.
Figure: Spiral model of the software process (adapted from Boehm, 1988)
Delivery of a version of the evolving project is a key milestone for each cycle. The project is reviewed and could potentially be stopped at the end of each cycle of the spiral. Each review event commits the project to further exploration and taking on additional risk, which is clarified and resolved in prototypes and simulations. Working prototypes or partial versions of the product are then produced and validated. Turns through the spiral expand progressively to include more and more of the waterfall’s activities (design, code, test, implementation, operations). The spiral can be used to manage small incremental project improvements or large uncertain product development projects.
A way of understanding the relationship between a development project’s cost, completion and risk is depicted (see below). The expanding circles reflect the cumulative cost of the project; the phase or % completion of each cycle is evident by progress along each cycle or turn. Risk and its trend (increasing or decreasing) are represented as a vector from the project origin (which shifts) to the current point in the cycle.
Figure: Spiral model 'risk, completion, cost disk'
The idea of ‘design risk’ reduces to being a factor of the people involved in a project. A low risk design element for an experienced engineer may be a challenging and risky job for an inexperience engineer. However managing the risk by reverting to the experienced engineer may be a short-term solution to what is in fact a different game running over the long term. Involving customers and users in prototype evaluation is a way of exploring requirements and further reducing risk.
By championing prototyping Boehm also provided a place for Royce’s advice to plan to ‘do it twice’ (Royce, 1970), i.e. a preliminary design and implementation that exercises all the other stages of the lifecycle. A development project undergoes a series of iterations or rounds; proceeding to the next round depends on how the preceding round went and on continuing viability of the business case driving the project.
Boehm’s spiral was the last significant theoretically driven contribution to high-tech project management up until 1999. Subsequent contributions to the burgeoning business of creating new life cycles and development methodologies were either hybrids of spiral/waterfall or techniques rather than whole project life cycles. For example Rapid Application Development (RAD) was founded on a single big idea, working prototypes. Iterative development is conceptually equivalent to spiral. Dynamic Systems Development Methodology (DSDM) was designed around the key concept of iterations. Participatory design, user driven development and Joint Application Development (JAD) give emphasis to user/customer engagement in the development process. The Rational Unified Process (RUP) gave credence to the manageability of large sets of projects and popularized the idea of automatic code generation from UML designs.
The break Boehm makes with the thinking of the day was to present a concrete actionable model for organizations to shift systems development from a batch thinking to process thinking perspective. That development was more like a process than assembly, where assembly lines move a product-in-progress from stage to stage to completion. The spiral model characterized development as an on-going cycle of expanding requirements (and risk) followed by resolving the requirement (removing risk) by creating new parts. An initially uncertain product idea gradually comes into focus over repeated cycles in an on-going process of discovery and refinement.
The process view of product development encompasses the batch view as each cycle can be considered a small batch.
CONCLUSIONS
New technologies in the form of better programming languages, more powerful computing hardware, new languages and development environments have held out the promise of improved production cycles for software and high-tech development. Unfortunately technological remedies are slow to evolve or when developed result in pushing the problem of design into other zones of the development ecosystem.
While the life cycle metaphor is certainly a useful way of characterising development activities and helps order or structure the working environment practitioners assert that the microscopic activities of programming are intrinsically bound up with each other and cannot be meaningfully separated. Cyclic or iterative process models like spiral are certainly better approximations of the underlying process of software design and production, and are therefore an improvement on earlier models. But at a macroscopic level, the level of teams and projects and organizations, stage-wise, and even cyclic process models like spiral simply do not capture the practical reality of programming. Ultimately life cycle models are mere organizational constructs, ways of ordering projects; they do not address the detailed production of systems design.
We have noted that stage-wise development models like the SDLC and waterfall become unmanageable for well-understood reasons:
- Software development tasks are complexly interdependent.
- Task interdependency demands close communication and coordination between workers.
- High-tech products are subject to uncertain and evolving requirements.
- The high-tech environment is constantly evolving.
Wednesday, 30 September 2015
Sunday, 27 September 2015
How do entrepreneurs do it?
A look inside NeXT. "Video: Steve Jobs brainstorms with the NeXT team (1985)"
Reality distortion field warning. Does this remind you of what goes on inside your own company? I'm tempted to think that the atmosphere the Jobs was recreating at the time was drawing on his experience with Apple, specifically trying to replicate the best bits (for him). My sense of the initiative is that they reverted very quickly into death march mode.
NeXt was 90 days old at the time, they initially anticipated a price point of $3,000. They were talking about an 18 month design and delivery schedule. At the second retreat the company was 180 days old and the project was already over budget, behind schedule and with an unclear feature list. Finally the first NeXT Computer shipped in limited quantities in 1988/89 with beta software and a price tag of $6,500. Not only had they designed a new computer and operating system embodying the most advanced and sophisticated technology of the day, they had also constructed an almost completely automated factory capable of manufacturing 150,000 units per year. Anecdotally they only ended up selling 50,000 units (Wired Magazine article and Wikipedia article).
Reality distortion field warning. Does this remind you of what goes on inside your own company? I'm tempted to think that the atmosphere the Jobs was recreating at the time was drawing on his experience with Apple, specifically trying to replicate the best bits (for him). My sense of the initiative is that they reverted very quickly into death march mode.
NeXt was 90 days old at the time, they initially anticipated a price point of $3,000. They were talking about an 18 month design and delivery schedule. At the second retreat the company was 180 days old and the project was already over budget, behind schedule and with an unclear feature list. Finally the first NeXT Computer shipped in limited quantities in 1988/89 with beta software and a price tag of $6,500. Not only had they designed a new computer and operating system embodying the most advanced and sophisticated technology of the day, they had also constructed an almost completely automated factory capable of manufacturing 150,000 units per year. Anecdotally they only ended up selling 50,000 units (Wired Magazine article and Wikipedia article).
Friday, 25 September 2015
#NoEstimates debate spreads
The #NoEstimates debate: An unbiased look at the origins, arguments, and thought leaders behind the movement - See more at: http://techbeacon.com
Tuesday, 22 September 2015
The Essence of Design: some notes
What is the essence of Design?
Competing on the eight dimensions of quality D. A. Garvin Harvard Business Review 65 101-109 (1997)
In Garvin's influential essay on the dimensions of quality (1987) he relegates aesthetics and perceived quality as the most subjective aspects of product design, the facets most open to interpretation and therefore least manageable and thus relegated to mere footnotes in the product management literature. The implication of this it would seem, is that "whole product experience" is perhaps relegated to footnote, that the essence of design, is essentially unmanageable, and yet...
Expressing Experiences in Design B. Moggridge Interactions 6 17-25 (1999)
According to Moggridge, design should satisfy many senses, not merely the eyes. Another way of putting this; design can harness many senses to better fulfil the designer's intent.
Since the Moggridge's article, the then rather unconventional examples, have, largely become mainstream products or features. The following products amplify some of these ideas:
Competing on the eight dimensions of quality D. A. Garvin Harvard Business Review 65 101-109 (1997)
In Garvin's influential essay on the dimensions of quality (1987) he relegates aesthetics and perceived quality as the most subjective aspects of product design, the facets most open to interpretation and therefore least manageable and thus relegated to mere footnotes in the product management literature. The implication of this it would seem, is that "whole product experience" is perhaps relegated to footnote, that the essence of design, is essentially unmanageable, and yet...
Expressing Experiences in Design B. Moggridge Interactions 6 17-25 (1999)
In contrast, Moggridge argues that the essence of design should in fact be the central focus of product design. The term he uses is 'Design Expression', the expression of the design. Design expression suggests the particular manifestation of a design. It is a holistic concept. The notion of 'expression' draws on and supports the language of design, design values such as: tradition, simplicity, elegance, complication, playfulness, youth, childhood, age, skill, strength, transparency etc.
According to Moggridge, design should satisfy many senses, not merely the eyes. Another way of putting this; design can harness many senses to better fulfil the designer's intent.
Since the Moggridge's article, the then rather unconventional examples, have, largely become mainstream products or features. The following products amplify some of these ideas:
- Heartbeat: from 2.40' into the video; Jonathan Ive's narration on the introduction to Apple Watch. See http://www.apple.com/watch/films/
- Force sensing: from 3.30'; recognising tap and press.
- The entire video continually emphasises the value of holistic integration of technology. Ive places huge emphasis on the aesthetics and the experience of using this device. How often does he mention the word 'expression'?
- On Kindle, "Amazon's new wireless reading device and the innovative things it can do". A conversation between Jeff Bezos (CEO Amazon) and Chris Anderson (editor in chief, Wired magazine) at BookExpo America 2008. See https://www.youtube.com/watch?v=kTM4pDdvqrU On Kindle, "its ability to disappear, to get out of the way". Avoiding the risk of "breaking the reader out of 'flow'".
- The original iPod http://www.apple.com/pr/library/2001/10/23Apple-Presents-iPod.html
- A video of the iPod launch event (link)
- Microsoft PixelSense http://www.microsoft.com/en-us/pixelsense/whatissurface.aspx
 |
| Montage of tabletop interface props used in Hawaii Five 0 series (search link) |
Usability Evaluation Considered Harmful (Some of the Time) S. Greenberg and B. Buxton 111-120 (2008)
All well and good then, but what is the essence of design? A finished product? No. Greenberg & Buxton (2008) contend that design is processual, a process that should remain rather open-ended as long as possible to explore, learn from and respond to that learning. Sketching is a crucial stage in HCI (human computer interface) designing. But they caution against making design appear too polished, that there is value in presenting it in rough form, as contingent and open ended, in order to facilitate learning (from the field, from users, etc). They caution against using high fidelity prototypes too soon.
The problem is that these working interactive sketches – especially when their representation conveys a degree of refinement beyond their intended purpose – are often mistaken for prototypes, i.e., an approximation of a finished product. Indeed, the HCI literature rarely talks about working systems as a sketch, and instead elevates them to low / medium / high fidelity prototyping status, which people perceive as increasingly suggestive of the finished product. Yet this perception may be inappropriate, for prototypes are very different in purpose from a sketch.
Monday, 21 September 2015
Media Analysis Method - Exercise
Media Analysis Method Exercise:
Watch and/or listen to the media (film, video, narrated presentation, audio recording etc.). Using the Research Notes for Media Template, make your own series of analysis notes, i.e.: factual observation + timestamp + research comment.
 |
| example of media analysis data capture sheet |
Time-lapse video data/method
I was curious about how useable the various ticketing systems used for the Luas tram system are. The Luas is a light rail tram running in Dublin, Ireland.
There are two lines, the green line running from St Stephen's Green to Cherry Orchard near Bray, and the red line running from The Point/Connolley Station, to Saggart in the South West of County Dublin. The Balally Luas stop is halfway along the green line (link to map of Luas Green Line stops) and serves the Dundrum Town Centre shopping district, nearby Airfield Farm and surrounding suburban area. https://luas.ie/balally.html
This video covers a 15 minute period, using time-lapse, the footage is sped up 2,000%. I added a blur to anonymise the citizens and a vignette to provide a focusing effect.
Watch the sweep pattern of the two security personnel in black.
Watch 5 trams pass through as the person in orange struggles with the ticket machines on both platforms, and still doesn't catch the tram.
Tags: Luas, time-lapse, public transportation, Dundrum, Ireland
Balally Luas stop, Dundrum, Dublin. by Allen Higgins on Vimeo.
An alternative to Product Roadmaps?
The product roadmap idea is ubiquitous in high tech development. So much so that we rarely challenge the idea, let alone question its usefulness.
Marty Cagan's post on the topic tries to do both, while at the same time presenting a better way of achieving the underlying goal. (link the alternative to roadmaps SVPG).
My view on this is that a product roadmap usually repeats that old problem of design versus need.
State the requirement in terms of the problem or goal that you want to address, rather than in terms of how you think it should work.
The essential character of a product roadmap is, ultimately, yet another GANTT chart (YAGC; a pretty horrible acronym after all).
Marty Cagan's post on the topic tries to do both, while at the same time presenting a better way of achieving the underlying goal. (link the alternative to roadmaps SVPG).
My view on this is that a product roadmap usually repeats that old problem of design versus need.
State the requirement in terms of the problem or goal that you want to address, rather than in terms of how you think it should work.
 |
| A collection of images produced by "product roadmap template" search term. |
The essential character of a product roadmap is, ultimately, yet another GANTT chart (YAGC; a pretty horrible acronym after all).
Friday, 18 September 2015
Tuesday, 8 September 2015
Starting a Tech Business by Alex Cowan
Alex Cowan's recent book on starting a tech business is one of the most practical guides I have found. This book brings it all together but in a way that is engaging, relevant, current, and, if it's not too difficult to believe, in a FUN way.
Alex's metaphors for each of the main periods the business undergoes are quirky yet insightful. The metaphors resonate because they capture an element of the truth. For example; The Lawn Gnome of Indolence, the Butterfly of Incoherence, Chihuahua of Unruly Development, and the Hydra of Operational Readiness; each of these metaphors says something, as wry but insightful observations on the character and challenges involved in tech business at different times.
Highly recommended as a guidance for entrepreneurs starting out on systems development or a tech business for the first time or even as a framework to refresh an existing business, product, system, etc.
 |
| Cowan's highly recommended "Starting a Tech Business". |
Alex's metaphors for each of the main periods the business undergoes are quirky yet insightful. The metaphors resonate because they capture an element of the truth. For example; The Lawn Gnome of Indolence, the Butterfly of Incoherence, Chihuahua of Unruly Development, and the Hydra of Operational Readiness; each of these metaphors says something, as wry but insightful observations on the character and challenges involved in tech business at different times.
Highly recommended as a guidance for entrepreneurs starting out on systems development or a tech business for the first time or even as a framework to refresh an existing business, product, system, etc.
A reflection on the themes, theories, and exercises of MDD
What is the focus of the MDD course? The course is designed to critique the lifecycle/methodology perspective and to highlight the necessary tension between orderly and responsive production of high tech systems. It draws a link between the management of systems development with its impact on innovation through technology.
How do the topics, themes, readings and exercises in the MDD course relate to the focus of the course?
Consider these two personas as the audience for this course:
- a business person participating within a development dynamic
- a developer interacting within a management dynamic
 |
| The themes, theories, and exercises. |
The material covers three fields of action or understanding that are ultimately linked by activity and processes.
- Basic Theories
- Methodologies or Frameworks (addressing the outward structure of organisation)
- Practices and Techniques (addressing micro-practices and interpersonal interactions)
Classroom discussions focus on the readings, cases, exercise or other topics. The benefits of discussion are:
- To review the subject matter.
- And more importantly, to familiarise students with the terminology and language of development.
 |
| Relating the themes and subject matter to the syllabus |
Each of you will have different knowledge and experience gaps. However the most important part of this exercise is you, the novice wishing to learn or the practitioner wishing to reinterpret your professional practice. You bring a questioning attitude (and a load of questions). The lecturer (and other members of the class) will bring their own experiences and knowledge to the setting in an attempt to interpret and address your questions, suggest alternatives, or suggest new sources of knowledge.
Comment:
Reflecting on the course, the subject matter and the material presented over the duration of the lectures it is obvious that, at the very minimum, the ideas in the readings are relevant as are the notes and slides on the themes, the optional readings, and perhaps more importantly, the learning you acquired through independent investigation. The book (Soul of a New Machine) and the case studies present opportunities to apply these ideas more broadly and in multiple ways. Consider reflecting at a personal level on own changed perspective or new understanding (or not but if not why not?). Are you able to relate the goals of the course to the content?
Subscribe to:
Posts (Atom)