Design, Develop, Create

Showing posts with label career. Show all posts
Showing posts with label career. Show all posts

Tuesday, 8 September 2015

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
and
  • 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)
The teaching method employs a seminar style with traditional presentation, discussions, case-based learning and practical exercises.
Classroom discussions focus on the readings, cases, exercise or other topics. The benefits of discussion are:
  1. To review the subject matter. 
  2. And more importantly, to familiarise students with the terminology and language of development.
Relating the themes and subject matter to the syllabus

Classroom discussion allows you to acquire and exercise your own knowledge and allow you to employ these terms and the language of development in a risk-free supportive environment.
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?

Tuesday, 1 September 2015

Introduction to systems development

This course reviews management perspectives on developing high-tech digital technologies and their characteristics. We discuss the implications for projects and work: organisational processes, methods, technique, tools and practice.

MANAGING SYSTEMS DEVELOPMENT
The innovation engine of an ICT-enable organization is its capacity to configure, construct, create, develop, deploy and maintain high tech systems. However, the collaborative production and delivery of robust systems presents significant challenges and team issues. An understanding of the tools and techniques used by professionals is therefore essential for managers who supervise systems developers or liaise with them during innovation projects. For each era and moment in the history of high tech development there is an associated technical backdrop representing the acme of infrastructure, technology and tools. The technical infrastructure is mirrored in turn by a social infrastructure – specialist knowledge, norms for communication, professional identity, behaviour, and expectations for teams. It is fruitful therefore to learn about the spectrum of current practices and apply theory to (critically) evaluate and subsequently adapt or formulate new processes, activities, and practices necessary for development in the situations we encounter ourselves; thereby better understanding and acting effectively in settings of high tech use-production.

How should a manager, software architect, designer, programmer, team lead or product manager,act to organize and manage high tech systems development projects? My goal is to help form answers to this and to the following questions:
  • What management techniques, practices, lifecycles and frameworks are applied in contemporary systems development projects?
  • How might we integrate the diverse concepts and theories of software systems development, and translate these concepts into personal, team, and management practice?
  • How is value generated and delivered in real situations?
  • What is the significance of new engineering approaches, from agile and lean methods to more functional approaches like CMMI and RUP?
  • How do lifecycles and methodologies balance the tension between a necessity for orderly production and quick responses to changing contexts?
The material covered includes current and emerging organizational/management approaches to development include: lifecycles like SDLC, Waterfall, Spiral; frameworks like CMMI, RUP, ISO 9001; and approaches termed ‘agile’ like XP, Scrum, and Lean Production. The key goal that these software production and systems development lifecycles address is how to create digital media, although they attach differing importance to the need for various system artifacts (design diagrams, code, documentation, issues, etc.).

The overarching objective for us here it is to explore how the generation of any or all system artifacts is produced by underlying social interactions such as joint development, peer review, user involvement, automated testing, use assurance. Consequently system development’s process and its context is itself a kind of social structure for managing production (in the development team) and users. Power is an essential and underlying concept in order to understand the 'assumed' orderly underlying social interactions of programming teams and others they need to deal with in order to 'get the work done'.

Why do we need to think about the processes and structures used for developing high tech products and services? It is true that the emphasis on organizing high tech production has shifted focus from gifted individuals to being a team-based mode of production if not a team-of-teams in case of large-scale infrastructural architectures. Engineers do not start and complete whole projects overnight. Producing value takes time, effort and many small instances of failure and learning to create viable systems. It takes time, people and other technologies to produce these things. Managing the process involves making trade-offs between the ordering of events and activities over time, access to other complex systems (software, tools, work techniques) and the services of other actors. Importantly the very idea of a system implies ‘use’ and modern innovation processes are increasingly reliant on lead user involvement to establish both how the system is used and consequently how it is designed (Von Hippel, 2005).

Positioning the role: managing high-tech production
What does a manager need to know about the IT function in order to manage it? The manager of the IT function needs to know how to go about producing the product, and also, how to go about producing users. However, rather than relegating ‘use’ to a phase of implementation and delivery at the end of the systems production cycle, ‘use’ and ‘users’ have become intrinsic to driving the development process. The following highlights ways of producing, delivering and servicing our demands for ICT, IT and high tech goods. We don’t need to be engineers to manage the process, but we do need to be technology savvy and know enough to make a difference; how to bring technology, business and users together. The technology manager’s role is to bridge the two communities of production and use, to translate, interpret and make sense of the gaps between the technological and customer worlds (Figure below).
Roles translating between technological and customer worlds.
From Scrapbook Photos



Sunday, 30 August 2015

Acquiring technical skills


On the topic of acquiring or refreshing technical skills I had mentioned codecademy.com
They deliver excellent self-paced community generated free technical skills training content.

Quite interesting too to appreciate how they have integrated the principles of Gamification into the service (badges, notifications, reputation etc) as a driver towards engagement, continuation and completion of tasks.

What Tech employers really want?

From Silicon Republic (link)

Experienced techies are in high demand...
A mix of financial software consultants...
Computer engineers, experienced and graduates...
Understanding the full range of a business...
A new venture demands understanding a problem...
Understanding customers...
Switchers from product management, sales and marketing...
Particularly interested in generic skills, to learn quickly, to fit in, attitudinal ...
Seeking people with a mixture of technology and business skills...
Technical skills, but also accountants and business...
Seeking people across the spectrum, sales operations, customer operations, supply chain management...
From commercial experience to engineering experience...
Data analysts, project managers, project roles...
'Smart people', who understand new ways of using technology...
Creative, innovative, flexible problem solvers...

Thursday, 6 August 2015

Areas of concern for digital product management

I believe that the following areas are those that should be the concern of, and areas of action for, digital product management.
Spotting where problems are in software, in code, in tests, in systems, in processes and procedures.
Collaborating with others to propose or identify or create solutions.
Needing to have a mental picture and idea of the whole product environment in order to understand technical possibilities and limitations.
Being able to follow if not run the full release cycle, usually with other's involvement and help, to produce a workable copy of the software and operate it.
There are whole specialisms and domains of knowledge that you need to be aware of if not expert in, for example:

  • Creating digital media including but not limited to; graphics, video, audio, fonts, text, formatted text, electronic books, styles, models, and many more.
  • Programming in various computer languages. Knowing the distinction between interpretable and executable software, between scripts, byte code and machine code, the necessary extras (libraries) that allow the software to run.
  • Wireframes, prototyping, paper prototypes, incremental and iterative development.
  • Testing, as a of broad specialism that also includes programming.
  • Source code control systems and document versions using github or subversion or cvs or other systems.
  • Packaging, installation, and package management.
  • Issues of legacy systems; in one way anything becomes a legacy system the moment it gets released. This area can be approached in different ways, data versus execution or running environments.
  • Localisation (aka l10n) and Internationalisation (i18n) are really important areas, unless of course you want to ignore international customers/users. Localisation is highly specialised but increasingly easier to address through the enhanced support offered by software development environments. So no more need to 'hard code' translations or language rules, these are now provided for by standard development libraries. So to, it is now a commonplace for computer fonts and character sets to support extended and unicode character sets allowing the display and use of text in any language, type, and linguistic framework. For example, left to right, right to left, top bottom, sentence patterns used in european, middle east and asian languages.
  • Online help systems including pop-up and context sensitive help, often the first and only documentation provided with software.
  • The components of and services provided by operating systems.
  • Managing vendors and other third party contributions.
  • Data visualisation.
  • Help desk and frontline support systems.
  • Sales and customer relationship management.
  • Quality management systems; not usually an area that software development prides itself on but essential and necessary nonetheless.
  • General technological infrastructure like internet protocol, ip addresses, networks, network protocols, subnets, routers, switches, wired and wireless, firewalls, packets, packet sniffing, shared drives, cloud storage, routers, domain control, ftp, port management, virtual machines, password managers.
  • Web hosting, website builders, domain registration and management, email server setup and settings, canonical name record (CNAME) and the Domain Name System (DNS) and IP addresses.
  • Content management systems, workflow and web services (things like Wikis, Wordpress, Joomla, Drupal and many others).
  • Databases, ranging over flat file, to relational, sql, object databases and post-relational databases.
  • Web services, evolving capabilities of HTML, REST, and other important API services.
  • LAMP architecture (i.e. Linux, Apache, MySQL and PHP) 
  • MEAN architecture (i.e. MongoDB, Express, AngularJS, Node.js)





Monday, 25 July 2011

How to manage development jobs?

How best to manage development jobs? The ancient assumption is to treat the work as a whole product in the form of a project, one of the most resilient and biggest ideas (assumption) underlying high-tech development.

The following posts (via the Agile Chronicles Newsletter) challenge this idea of the 'one big thing' that everyone works on.

Teams over Projects by Brian Bozzuto (June 27, 2011)
You may find this counter-intuitive, but I would posit that many traditional organizations use broad project portfolios as a means of achieving agility. With the heavy ramp up costs of any given project, having multiple options to respond to change. We can ramp up or down our energy on any given project based on changing circumstances or priority. While it’s not terribly flexible, it does offer some level of adaptability. However, it comes at the price of running all these projects at the same time, which is a very steep tax when you start adding up the cost of multiple status reports, daily or weekly meetings, code branches, design documents and any other overhead required for running your projects...

Do You Have Feature-itis? by Johanna Rothman (July 22, 2011)
Feature-itis. It’s an agile Product Owner game. It’s when the Product Owner says, in his or her best George Carlin voice, “Gimme Features. I don’t care about no stinkin’ framework.

Kanban, Scrum/XP and the Paradox of Constraints by Jim Bird (July 13, 2011)
If you find it difficult to break your work into time boxes, if your work is highly interrupt-driven like in many maintenance and support shops, then Kanban offers an alternative control structure. I am not sure that I buy into its manufacturing control-line metaphor, and that all of these ideas map well from manufacturing to the highly variable work involved in building and supporting software.