#nubismurfit

Thoughts. Comments. Lessons. Starting the the module - Managing Systems Development at the UCD Smurfit School of Business.

[nubismurfit]

5 Takeaway Points From The MSD Term Project

The end of the module saw me pair up with a colleague to work on the term project. We both worked on the UCD Smurfit Self-Service Checkout System and the aim of the project was to look for problems with the system and propose solutions. 

You can check out a 4 minute video summary here, and some takeaway points for me from the project:

Research Methods: It was important to determine how to go about the project, in terms of how to get the needed information and this saw us applying different methods to different people. Observation (LOOK) and Survey (ASK) for users, and well as Inquiry (ASK) from the UCD Library and systems manufacturer (3M).

Expect the Unexpected: It is always good to open one's mind to unexpected results and reactions, as we did come across a number of these during the project. It is not safe to assume for people but instead ask or let them tell you what they want in a system/product/service.

Sketching is a Valuable Tool: Wire-framing our recommendations, and sketching systems flow did help in developing and communicating our solutions as well as getting feedback.

Think Micro and Macro: On starting the project, I was only thinking micro - i.e., focus on just the self-service checkout machine and how to make it better from a user's point of view. However on completion I was thinking macro - bringing in other players like the librarian (support), manufacturer, testers, and management.

Team work: I don't think I have ever found myself in as many teams at the same time as I did this semester at UCD Smurfit and it was a valuable experience for me, especially on the MSD project. Working with Leah was valuable as we brought different perspectives to execution and it did pay off in the final output of the project. 

Thanks to everyone that contributed to my learning. Managing Systems Development was indeed a valuable module for me as I now have a clearer idea of career options and responsibilities that come with these roles - especial the one of a product manager interfacing between business and technology.

[nubismurfit]

People, Tech, And Systems Development

Systems development involves both people and technology, and thus the need for interaction. The two types of interaction here include: people-to-people, and people-to-tech, or better yet, social and technical as seen in the Sawyer article.

The former sees people interact, behave, and organize, while the latter covers production methods, development techniques, and computing technologies. Taking this back into software development, there seem to be three structures (archetype) that can be adopted by teams.

The first is sequence which is a linear process of system development. Individuals in this setup are responsible for specific points in the sequence and it's all about the skill possessed.

The second is group, and this is often used where development is coupled with production as independent teams work on stages and individuals have to own skill required as well as the ability the work in teams. 

The third is the network structure which sees system development as a circular process and individuals and teams will need people skills as there is need to interact with other players - users, designers, managers, etc.

It is however clear that the type of structure adopted is dependent on the context of the systems development project. Good thing one is not constrained to just the three options as hybrid models can be implemented as well.

Photo Credit: joelogon via Compfight cc

[nubismurfit]

Collective Creativity - Harnessing The Power Of Diversity

The thought of collective creativity did seem uncool to me prior reading the article from Hargadon and Bechky, as I would have rather preferred individuals being creative and then sharing their outputs to the group.

However the argument for collective creativity is very compelling in the sense that:

an organization gets to attain quality and defined standards to which its work can be attributed as found in the top creative agencies.

experience and competence is developed over time

However, I'd recommend that there is need to avoid grouping in terms of creative perception, such that individuals get stuck to the status quo. A good way to keep things interesting is have team members engage in diverse creative activities that are not related to work so as to keep perception and input fresh.

For collective creativity to work, the individual has to be competent in some interactive approaches such as help-seeking, help-giving, and reflective framing (all self explanatory) while management provides the necessary reinforcement in terms of enabling environment and tools required to attain collective creativity.

Now that I think of it more, maybe collective creativity is cool as that was exactly what happened as I worked with my team in building the spaghetti bridge.

Photo Credit: 'PixelPlacebo' via Compfight cc

[nubismurfit]

The Context of Agile In Software Development

The two readings - Extreme Programming Compared with Microsoft-Style Iterative Development and Voyage in the Agile Memeplex confirmed my thoughts on the agile practices and traditional software development - from water fall to iterative development.

What's this thought:

Agile Processes are just selected software development practices that have been seen to work - increasing productivity and efficient use of resource - time, money, and people (skill).

These agile process - some of which are found in extreme programming (XP) including: Planning around User Stories, Pair Programming, Simple Design, Refactoring, Continuous Integration, etc. are seen to exist in similar forms in traditional systems development as seen at Microsoft.

Although Mr Beck (the XP guy) says this is at an abstract level, truth is agile is just a better way of building software after filtering what works and doesn't. So no point trying to make Agile process such as the XP so out-of-touch as that even causes a perception problem as regards efficiency as seen in the Agile Memeplex piece.

Some will argue that agile is for small project, but how about breaking down complex project into smaller once and applying agile. After all it's all about context and not size of the project. Once there is a consensus (aided by planning poker), programmers, developers, product managers, users representative can work with applicable agile processes in developing quality software.

There is always going to be a trade-off between agile processes and the traditional methods of software development; the latter yielding new types of the former and adopting defined versions - as long as it fits into the context  of application.

[nubismurfit]

#WeCodeHard... And Fast: Architecture & Agility

Having spent sometime working out of a tech incubator for about 18 months, I did get to see agile programming in action with practices like pair programming and unit testing, but the article - Embracing Change With Extreme Programming (XP) - did shed more light on this method of systems development.

I did find myself retuning on my post on Scrum and Software Complexity, and not surprised the XP is somewhat a new-gen version.

The Waterfall - Analyse > Design > Implement > Test which happens to pop every time when system development is mentioned seem to be the core of everything and it only makes sense to explore the XP method of system development due to factors including:

inability to get systems specification from the customer 

the need for iterations and further development from feedback

limited resource - money, time, and skill/people

The scope of the project is needed to be taken into consideration as that controlled allows for avoidance of pitfalls such as: underestimation, turnover, among others. Personally I'd recommend this for short time-bound projects with a team of designers, programmers, and testers.

With an interest in mobile and web app technology, and other simple systems, where prototyping is expected to be fast - to even see if there is a market or investors are ready to put in cash, the XP may just be the way to go.

[nubismurfit]

Quality - The ISO And SDLC At The Work Place

One gets overwhelmed with the hardware display at a shuttle launch, but the magic really happens in the area of software, as any errors and everything goes wrong. Hence the focus on precision that nears perfection - as it's really not the amount of work but how well the software works.

Now to achieve this, programmers need to design process and develop a culture that aims at group perfection. This often happen at the Shuttle Group - NASA meetings and two things can be taken away fro this:

Hierarchy and dependency (on one particular person) is eliminated, which is a good thing for a complex software such as one that flies a shuttle.

On the downside, creativity is stunted. You have to follow the manual when it came to software - for safety/security. Every bit of creativity went into process. 

With the Plan - Design - Code module, nailing the process meant having the best possible software. Other practices adopted such as fixing the problem as well as the cause, and healthy rivalry in team work, i.e. coder - verifier, and developer - tester relationships, contributed to quality software (99.9% error free).

As software gets more common but less reliable, one sees the importance to adopt some of the SDLC practices at the Shuttle company, even though it is safe to say the type of software built did need to be as perfect as possible and there was no constraints.

In terms of ISO standards, it is seen as quality-management mechanism, and while some problems come with quick-fix solutions, others requires a revisiting the process and design - including training. 

Nonetheless, adopting these standards, even if difficult for small companies due to paper work and documentation, often contribute to maintaining quality even when dealing with suppliers and subcontractors.

There is always need to aim for quality, especially when it improves the product and in turn profitability.

[nubismurfit]

Thinking Economics: The Kongregate Games Case

System design involves a level of creativity as one would often need to sketch, as well as good understanding on basic arithmetic - at least that's the lesson from the Kongregate Game Case.

To make a decision on which economic model to go with, there is need to evaluate possible cases, and take into account important factors like: Return On Investment (ROI), Payback Period, Present and Future Value, Internal Rate of Return, Cost - total, average, and marginal, etc.

All of these helps in building the framework for an IT investment. With the Kongregate platform giving game developers options of making revenue by publishing on the platform, doing so exclusively, and having an API, there is need to work the maths and decide if it's a worthy investment.

It often goes away from the maths, as some strategic questions need to be asked to end up at a decision, but understanding the economics goes a long way in making the right ones.

Extra: Compatibility drives profitability. In the sense that the more compatible your product/service/system is the more value it offers, and in turn profit.

[nubismurfit]

The Avalanche Case of Systems

Another tricky on at the start but with time the points of the avalanche case became clearer. 

Getting into the role of a product manager, you need to understand how a system works and the link between players - including designers, users, standards and policy regulators, market, production, and other individuals and teams.

So with the transceiver as the product, I got working with my team mate on identifying the players and links to end up with this:

A more comprehensive version from contributions of the whole class sees more players and links emerge. Although it is not always easy to complete such a map at a quick go, it gives the product manager a good understanding of the product, people, and process involved. 

Interestingly this helps understand all there is to know about a product, unveiling information that can be shared with investors, users, production team, marketers and others - thus making it a worthwhile exercise when it comes to systems development.

[nubismurfit]

Activity Checklist And The Space of Context

Perhaps the most complicated reading for the semester, but here are my line of thoughts as regards Activity Checklist - a more concrete spin off from the abstract phenomenon of Activity Theory. 

Context is very important when it comes to system design. Techniques such as risk analysis, participatory design, and contextual design are often applied for context in design and evaluation.

Albeit, activity theory which is simply involves humans (subject) and activity (social cultural rule) with other humans and technology (object) is often guided by the perception based on location - looking at the whole picture from the outside or a part of it from the inside.

However, with the activity checklist which is meant to be used with other techniques when it comes to system design and evaluation, it becomes easier to cover the contextual factors.

Applying the activity checklist involves:

Using it with other techniques to ask the right questions, and gather the right data

A non-linear method when covering the parts of the activity checklist including 'means and end', environment, 'learning, cognition and articulation', and finally development

Getting familiar with the activity checklist itself and internalizing it.

In conclusion, the Activity Checklist does simplify the process of system design and evaluation, and although it is not meant to be used alone for this purpose, it guides the designer on effectively covering the scope of context.

[nubismurfit]

Planning Poker: Group Understanding Over Grouping

I'd admit it was rather strange for a couple of graduate student sit around the table while cards no. 1/2, 1, 2, 3, 5, and even some carrying the '?', and infinity - ∞, but with time the whole concept of planning poker got clearer.

The practice involved getting the specifications - goals and objectives of a client (the person requesting for a system to be developed), and then having the systems engineers, developers, designers, project manager, and other players decide on estimations - usually ideal days - to complete tasks, modules, and project.

For example, how long time to move from point A to B, and then players draw out card(s) with the estimations. If all draw the same card, it's an agreement, else, players debate for reasons and re-draw until a consensus is reached.

As a colleague mentioned after class, this is best used for sprint development, and I'd agree as it may not work for more complex and grander projects (perhaps if such project is broken down first into blocks and sub-blocks, then planning poker applied).

Nonetheless, an important point I got was sent out in a tweet in class below. It's all about encouraging group understanding and not grouping which often comes from one team member anchoring others to a view, perception, and estimation.

Planning Poker encourages group understanding rather than grouping from anchoring. #sysdev

— Nubi Kay' (@NubiKay) October 1, 2013

Any thoughts?

[nubismurfit]

Chaotic Scrum Engineer And Software Complexity

Here are my thoughts on the readings: No Silver Bullet, Scrum + Engineering Practice, and Chaos Model and Chaos Life Cycle.

The software industry, especially those at the engineering end, yearn for simplifying the complexity that comes with production (i.e. design and programming), and have taken steps in making that happen via high level language, peer programming, etc., but all of these do not simplify the core of software engineering - conceptual construct - including specification, design, and testing. 

The human mind plays a big role in constructing concepts, and that yields to the recommendation of gunning for great designers at the same level a software company do for great managers.

Further more the application of the metaphor of chaos model to software engineering, shows that the developer pulls the strings of program end (influenced by user's need) and line-code end (influenced by technical resource). Thus, the more competent and creative the developer (software engineer), the less complex the process becomes.

The closest to proving this is Microsoft experiment which backed scrum (an agile software development process that hinges of a programmers creativity) with engineering practices. Using defect density as a measure of success, it was seen that coupling these two methods gave better results (excluding the set where testing - another engineering practice, was reduced). 

Perhaps, the silver bullet to the werewolf called software engineering is not of moon metal, but made out of a mixture of agile software development and sound engineering practices.

What do you think?

[nubismurfit]

Cognitive Mapping - Stuff That Really Matter

Cognitive Mapping. Another interesting exercise for me as it involved experimenting outside of the classroom.

My partner, Conor, and I took to a split experimenting between existing maps such as navigating from UCD Smurfit to UCD Belfied, and virtual space such as a website.

We got a total of 14 people to either sketch a map of how they'd move from Smurfit to Belfield as well as highlights landmarks along the way, or sketch a website they often or recently visited. We also performed the experiment on ourselves and got the following findings:

Existing Maps

People often simplify map sketching into lines and angles (rather than curves and corners).

People often remember utility buildings like school, shopping centre, post office, fast foods, churches, and hotels

People remember structures like pedestrian bridges, and high traffic light zones.

Virtual Spaces

While some people remember images, some discard them for just basic site structure.

Most people remember only parts of the site they engage with such as Call-To-Action buttons, Contact Us, etc.

Most people remember the logo position as it mostly on the top left corner.

Most people do NOT pay attention to the bottom of the site (out of page content that need scrolling to be visible).

Other observation included swapping content positions, change arrangement of text from column to row, as well as ignoring top menu buttons not in use.

In summary, the exercise showed the importance of users feedback in design - websites and maps, and how people easily discard useless or unused information from spaces.

[nubismurfit]

Lego Mindstorms: Creative Problem Solving

I remember getting to class to see the Lego Mindstorms on table brought memories of the time I spent at a tech incubator back in Nigeria, and I even sent out this tweet:

Look what I found in class today! Mindstorms Lego. Guess I should have picked up interest at the #cchub @tunbosunt. pic.twitter.com/cRbNsoNujZ

— Nubi Kay' (@NubiKay)

September 17, 2013

The exercise saw me work in a group, and carrying out operations such as sourcing (for parts), building, and guiding the builder with instructions from the manual. 

The team was pretty flexible and we took turns at different roles, and it did pay off as finished in good time. We did learn some lessons along the way and upon reflection including:

See all you've got to work with before commencing. Not necessarily everything but major components like instruction manuals (as we noticed late there was the coloured version which made development easier).

Learn to adapt. We got to a point of development and noticed a flaw in design, but we quickly adapted and fixed the problem without the need of going back to square one.

Pace yourself. Look at the whole projects and see how many steps or stages are involved and then pace yourself so you don't spend too much time on more difficult development when there are easier to compile  parts ahead.

Other points I picked up from other groups included, the importance of delegation, as they would have covered more grounds if some were sourcing while others were building. 

In all, it was a great experience, and who could have thought all that would come from a Lego Mindstorms.

[nubismurfit]

Lessons From NATO Proceedings (1969)

If you have not read the lessons from the 1968 proceedings you can do that here first before reading on.

The issue of scale seem to resonate through out the 1969 NATO Software engineering proceedings. With the birthing of large systems come the complexity, and the arguable need to have large resource including people, time, and budget.

Nonetheless, control and flexibility are key features a manager must possess as there is need to adapt to different circumstances. People and management are other factors to be considered as skills are needed and have to be properly managed.

While large teams come with many problems as conflicts and misunderstanding, the team at NASA show that after working together for years, team rapport is created and yield good result. The designer-engineer working relationship, as well as modelling practices further enhance quality.  As far as control is concerned - defining modules, assigning responsibility to individuals, review, and documentation contributed to the success of the NASA - Apollo 11 program. 

For Bell Technology, the issue of hardware compatibility to software systems seem to be the heart of major bugs and errors the company face.

A final and major note from the 1969 proceeding is the Software Engineering versus Computer Science, and the proposition to have a new curriculum for the former. Reason because Software Engineering saw more of practical and theory or better yet production/implementation focused, while Computer Sciences is design/theory focused. 

In my opinion, a software engineer is a computer scientist who goes further from design to production. Not to say a computer scientist cannot do this, but s/he is more interested in design and theories.

What do you think?

[nubismurfit]

Lessons From NATO Proceedings (1968)

After what I'd consider a long but interesting read, here are lessons I got from the NATO Proceedings on Software Engineering:There is always need for users involvement when it comes to design and production (especially iterative types), as feedback is quite important and validates. However on should not be caught in the trap of trying to make every user happy, as a majority is fine.

Again the need for feedback cannot be emphasized and it makes production more effective when this is done at every stage. Although with this (and planning), an amount of delay is added to the process, but it makes for time that should have been spent fixing problems later on.

Another lesson is one of software dependency on hardware, as well as the contrast between design and production. I'd agree that even production is dependent on design, it allows for going back to make the design even of better quality, i.e.., iterative re-designing. 

A few points from the Key Note include point of software engineers addressing the problems faced by many, and should thus be competent in coming up with effective designs and useful products. In support of that, the need to collaborate.

As for the sequence of writing software by S.Gill, both options of top-down (flowchart), and bottom-up are adopted by programmers and designers respectively, but a fine mix of both is need for successful execution of projects.

That's not all. It get's more interesting in the 1969 report. Click here for lessons from that proceeding.