Personal Blogs

Over the last year I’ve taken over as the incoming module chair for TM354 Software Engineering, taking over from Leonor Barroca, who has done a brilliant job ever since the module was launched back in 2014. I first learnt about TM354 through a module briefing which took place in September 2014.

What follows is a summary of the various elements that can be found within the TM354 module website. I’ve written this blog whilst wearing my ‘tutor hat’; to help students who are new to this module.

It goes without saying that two of the most important elements are, of course, the module calendar, and the assessment page which provides access to all the TMAs. One thing that I tend to do whenever I study a module is to get a printout of each of the TMAs, using the ‘view as single page’ option, just so I get an early idea about what I have coming up. You should also take some time to review the module guide and the accessibility guide.

Key resources: the blocks

TM354 is based around three printed blocks which can also be downloaded as PDFs by visiting the resources tab:

• Block 1: Units 1-4 From domain to requirements
• Block 2: Units 5-8 From analysis to design
• Block 3: Units 9-12: From architecture to product

Complementing these blocks is, of course, the module glossary, which can be accessed through the resources pages.

In OU modules, the glossary is pretty important. It presents the module team’s definition of key terms. If there is an exam or an EMA question which calls for a definition, you should always draw on terms that are defined by the glossary. A practical tip is: do spend time looking at and going through the module glossary.

Software

There are three bits of software that you will need to use, and the first of these is optional:

A sketching tool: In your TMAs you will be required to draw some sketches using a graphical language called the unified modelling language (UML). UML is a really useful communication tool. It can be used to depict the static structure of software (which bits it contains), and the dynamic interaction between components (which is how they are used with each other). How you draw your diagrams is completely up to you. You can draw a sketch by hand, draw a sketch using the tools that you have in your word processor, or you can download a tool to help you. My recommendation is to use a tool that specifically helps you to draw UML diagrams. This way, the software gives you a bit of help, saving you time (although you have to spend a bit of time learning a tool). I use a tool called Visual Paradigm, which is available under a student licence, but other tools, such as UMLet might be useful. There are a lot of tools available, but if you’re pressured for time, a pencil, ruler and paper, and digital photograph will be sufficient.

ShareSpace: this is an OU tool which you will use to share some of your software designs with fellow students. Software engineering is a team sport. ShareSpace is used to simulate the sharing and collaboration between fellow software engineers. As well as posting your sketches, you will be asked to comment on the design of fellow students. When you leave comments, you will be able to see comments about your own design.

NetBeans: Netbeans is an integrated development environment; a tool for developing software. You will use Netbeans in the final block of the module to look at, and change some software code that relates to design patterns. If you’re familiar with other development environments, such as IntelliJ, or even BlueJ (from earlier studies with M250) you could use those instead.

Forums

The module has a number of forums. A practical recommendation is to subscribe to each of these, so you are sent email copies of the messages that are posted to them. 

There is a module forum, where you can ask questions about the module, and a forum for each of the TMAs. You can use these TMA forums to ask questions about the assessments if you’re unclear about what you need to do. Do bear in mind that the moderator can only offer guidance and might direct you towards relevant bits of the module materials.

There is a tutor group forum, where you can interact with your TM354 tutor. Your tutor may well share some materials through this forum, so it is important that you subscribe to it, or check it from time to time.

There is what is called a ‘online tutorial forum’. Tutorials are run in clusters. What this means is that groups of tutors work together to offer a programme of tutorials (which are sometimes known as learning events). These tutors will use this forum to share resources that relate to their tutorials. They may, for example, post copies of PowerPoint presentations that formed the basis of their tutorials, which may contain useful notes in the notes section of each slide.

Finally, there is the café forum. This is an informal area to chat with fellow students about TM354 and OU study. This area isn’t extensively monitored by the forum moderator.

One thing to note is that sometimes the names of these forum areas can and do change. The names of the forums here might not be the names of the forums that you have on your module website.

Study guides

Although most of the module materials are available through the printed blocks, there are some important elements of the module that are only available online. Within the module calendar, you will see study guide pages. To make sure you go through each of these. Sometimes, these guides are presented along side other accompanying online resources that you need to work through to answer some of the TMA questions.

Resources pages

The Resources pages (which is sometimes known as the resources tab) is a place that collates everything together: all the guides (module, accessibility and software guides), PDF versions of the blocks, online version of each of the units (which can be found within each of the blocks), and any additional resources that need to be studied:

• Choosing closed-box test cases
• Monoliths versus microservices
• Introducing Jakarta EE
• Implementing use cases

Towards the bottom of this page, there is a link to a zip file which contains some source code that is used with TMA 3, along with some NetBeans software installation instructions.

The final bit of the Resources pages that I would like to emphasise is the Download link, which can be found on the right hand side of the page. Through this link, you can access all the module resources in different formats. You can, for example, download some of the media files onto your mobile device for you to review later, or you can download ePub versions of all the study guides and units onto an e-reader.

iCMAs

TM354 also has a set of interactive marked assessments (iCMAs). These are designed to help you to learn and to remember some of the key module concepts. The iCMAs do not formally contribute to your overall assessment result.

Tutorials

Before my final section, I’ll say something about tutorials. Do try to attend as many as you can. There are tutorials that introduce you to each of the block, and help to guide you through what is required for the TMAs. There are also a series of exam revision tutorials. Do try to attend as many as you can, since different tutors will present ideas in different ways.

Reflections

There is quite a lot to TM354; there are a lot of resources, which take a lot of reading. To familiarise myself with the materials I’ve taken an incremental approach: studying a bit at a time. Although the printed blocks are central to the module, it is important to pay attention to the online materials too.

My biggest tips are:

• Get a printout of the module guide.
• Get a printout of each of the TMAs.
• Make sure that you thoroughly read the module guide. You might want to get a printout of this too.
• Do remember to regularly refer to the module glossary. These definitions are important.
• Attend as many tutorials as you can.

On the TM354 Software Engineering module forum, the following question was posed: ‘does anyone know of any software engineering podcasts?’  TM354 tutor, Tony Bevis gave a comprehensive reply. With permission, I am sharing selected elements from Tony’s post, listed in no particular order.

SE Radio

This SE Radio (se-radio.net) is pitched as the podcast for professional software engineers. The following sentences are drawn from the SE Radio about page: ‘The goal is to be a lasting educational resource, not a newscast. …  we talk to experts from throughout the software engineering world about the full range of topics that matter to professional developers’. It is interesting that this podcast has a formal link to a recognised publication: ‘SE Radio is managed by the volunteers and staff of IEEE Software, a leading technical magazine for software professionals published by the IEEE Computer Society. All content is licensed under the Creative Commons 2.5 license’. Episodes appear to be quite long; an hour or so.

What the Dev?

What the Dev? is a podcast from SD Times magazine. It is said to ‘cover the biggest and newest topics in software and technology’. The magazine has an accompanying weekly email newsletter which contains a summary of current technology news items and a weekly podcast. Each podcast appears to be relatively short. The ones I have listened to were approximately 20 minutes.

Agile Toolkit Podcast

Agile is an important software development approach. The Agile Toolkit podcast 

aims to share ‘conversations about agile development and delivery’ through an archive that runs from 2005 through to the current day. They appear to be pretty long, so if listening to podcasts to learn more about agile, it is important to be selective in terms of the podcasts that are listened to. 

Open Source Podcasts

Open Source technology is an important subject to software engineers. When doing a bit of internet searching, I discovered something called the Open Source Podcasts last.fm channel which aims to share ‘conversations and advice from Open Source technologists on a wide range of topics’ and summarises links to a range of different podcasts.

A quick search for the term Software Engineering on last.fm takes me to a podcast channel called Software Engineering Daily. It really does appear that there is a topic or a technology made available practically every day. These podcasts range in length between half and hour and an hour.

Reflections

There are a lot of resources out there. There are so many podcasts and recordings, that I feel overwhelmed. I have yet to establish a regular podcast listening habit, and I have yet to find a convenient way (that works for me) to access these different channels.

I quite like What the Dev? since the episodes are quite short; I can be listening to a couple of these whilst getting on with other things. It is good to note that the first one mentioned on this blog is recognised by the IEEE Software magazine, and this deserves a more detailed look. The daily software engineering podcast looks to be of interest too. 

What is surprising to me is how many bits of technology that feature in these podcasts that I don’t recognise; a lot is new to me. I’m hoping that some of these podcasts will enable me to learn more about new technologies, understand their role and purpose, and how software engineers might use them.

Acknowledgements

A big thank you to Tony. I’m going to be doing a lot of listening!

When I started to do some background reading into how TM354 Software Engineering might need to be updated, I was guided towards two curious novels. 

From October 23 I start to study A233 Telling stories: the novel and beyond, as a part of my gradual journey through a literature degree. For quite a while, I have been thinking there have been very little to connect novels and software engineering, other than obvious: the development of Word processing tools that can be used to write novels, and the Amazon cloud infrastructure used to distribute eBooks.

What follows is a very short (and not very through) review of two books that are all about DevOps: The Phoenix Project, by Gene Kim (and others), and The Unicorn Project, which is also by Kim. 

The Phoenix Project

I shall begin by sharing an honest perspective: the idea of a novel about software development did not excite me in the least. The text has a subheading that seemed to strengthen my prejudices: “a novel about IT, DevOps, and Helping Your Business win”. This is no crime drama or historical novel. The closest genre that one could attribute to The Phoenix Project is: thriller. I feel it occupies a genre all of its own, which could be labelled: IT business thriller.

The main protagonist is Bill Palmer, who has the unenviable job title of “Director of Midrange Technology Operations”. Bill works for a mysterious American company called Parts Unlimited. A lot happens in the early chapters: Bill is invited in to have a chat with a manager, who gives him a promotion. He is then asked to take a lead in getting the Phoenix Project, a new mission critical software system to work. Failure means the business would lose any potential competitive advantage, and the IT infrastructure might be outsourced, which means that people would lose their jobs.

Before Bill can get settled, he is hit by a payroll outage, which means the employees and unions are angry. He also quickly realises that the whole IT setup is in a complete state. Kim and his co-writers do a good job at attempting to convey a sense of paralysis and panic. The reason for this is expressed through the notion of ‘technical debt’, which means that existing IT infrastructure has become increasing complicated over time. Quick fixes now can, of course, lead to further problems down the line. Parts Unlimited has not been ‘paying down’ their technical debt.

An important element of the novel is the division between the Ops (operations) bit of IT, and the development division. There are other competing teams, which also play a role: there is the QA (quality assurance), and the security team. Security is important, since if an organisation doesn’t keep its auditors happy, the directors may face legal consequences.

I think I would be mean to describe the characters as one dimensional, since plot clearly takes precedence over characterisation. The main protagonist Bill is the most richly described. His organisational skills and sense of calm in the face of chaos is explained through his military background. 

Ubergeek Brent plays an important role, but I really wanted to know what made him tick. Erik Reid, an unofficial mentor to Bill plays the role of a Yoda-like mystic who provides insightful advice, who draws on his extensive knowledge of lean manufacturing. A notable character is Sarah Moulton, the Senior Vice President of Retail Operations, who takes on the unenviable role of the villain.

What struck me was the amount of technical detail that exists within the text. There are references to services, languages, and source code management. There is also the important notion of the ‘release’, which is a persistent problem, which pervades both this text, and its follow-up. Whilst I enjoyed the detail, I’m unsure about the extent to which the lay reader would grasp the main point that the book was making: to gain efficient business value from IT, it is best to combine together operations and development. Doing this enables the creation of tighter feedback loops, and reduces operational risk. Along the journey, there are these moments which raise an eyebrow. An example of this is where there is unambiguous contrition from a security manager once he sees an error in his thinking.

Bill identifies barriers and instigates change. After a “challenging” release of Phoenix, he ultimately prevails. During the updates, there is the emergence of a ‘side project’, which makes use of new fangled cloud technology to deliver value to the business. In turn, this generates income that makes shareholders happy. Political battles ensue, and Bill then gets on a fast track to a further promotion.

Apparently, The Phoenix project was popular amongst developers when it first came out, but I’ve been peripherally distant from the domain of software engineering, which means I’ve been a bit late to the party. Before providing further comment, I’ll move onto the sequel: The Unicorn Project.

The Unicorn Project

When I read The Phoenix Project, one of my criticisms was about the identity of the main protagonist. Novelists can not only use their craft to share a particular reality, but they can also have the potential to effect change. Whilst I liked Bill and the positive role that he took within the novel, given the clear and persistent gender disparities in the sector, I did feel that a female protagonist would have been more welcome. This unarticulated request was answered through The Unicorn Project in the form of Maxine Chambers, the lead protagonist in Kim’s follow up novel. 

Maxine is collateral damage from the payroll failure. Despite being hugely talented, she is side-lined; temporarily reassigned to The Phoenix Project. Her starting point was to try to get a build of all the software that was being developed, but faced persistent complexity, not just in terms of software, but in terms of finding out who to speak with to get things done.

Whilst the main project was saturated with bureaucratic burden, Maxine gradually found “her people”; smart like minded people who were also frustrated by the status quo. She also spoke with the business mystic and mentor, Erik Reid, who was very happy to share his words of wisdom. Ubergeek Brent also makes an appearance, but his backstory continued to remain opaque.

A really interesting part of the text is where Maxine ‘goes into the field’ to learn what happens in the Parts Unlimited stores. Drawing on the notion of ethnographic observations, she learns first-hand of the difficulties experienced by the store workers. Another interesting element which occurs towards the end of the novel is the movement towards embedding institutional learning, and drawing upon the creativity that exists within the workforce. In comparison to The Phoenix Project, there is more emphasis about culture, specifically, developing a no blame culture.

A key theme of The Unicorn Project is shared with The Phoenix Project: it is important to combine development and operations together, and it is helpful to perform continually integration since users can gain access to the new features more readily. A notable section highlighted the challenge of carrying out code merges during marathon meetings. If code is continually integrated, then there isn’t the need for all those uncomfortable meetings. Significantly, the Unicorn project also goes further than The Phoenix Project, since it is also about the power of teamwork, collaboration and the potential of smaller projects positively affecting and influencing others. Like Bill, the formidable Maxine is successful. 

Reflections

My initial scepticism of these novels comes from my view that novels are made from story and character, not technology. What is very clear is that although technology plays an important role, people are, by far, the most important. The novels foreground the role of teams and their organisation, the importance of sharing knowledge, and the importance of collaboration and leadership. It is clear that soft skills matter for the simple reason that software is something that is invisible; developers must be able to talk about it, and to each other. This is also why organisational culture is so important.

An important reflection is that both Bill and Maxine have difficult and very stressful jobs. They are both shown to work ridiculously long hours, often over the weekend. In the novels, IT is depicted as a difficult occupation, and one that is far from being family friendly. The families of both protagonists are featured, and they both suffer.

Although both of these novels are stories about the success of heroes battling against impossible odds, the hyperreality of the chaos within Parts Unlimited makes their success difficult to believe. Conversely, the hyperreality that is expressed through the impossible administrative burdens of the ticketing systems offers a warning to those who have to work with these systems on a daily basis.

The mystical mentor Erik is, of course, difficult to believe. He is a device use to share the pragmatic business and manufacturing theories that are central to the themes that are common to both books. I didn’t mind Erik. Like with Brent, I wanted to know more of his backstory, but with a limited work count and a lot of themes to work through, I understand why creative trade-offs were made to foreground more pressing technical topics.

Whilst I found the broader context, automotive spares, mildly interesting, I found myself becoming bored by the theme of IT being used to gain ever increasing amounts of money through the persistent and relentless pursuit of the customer. Although I accept that IT can be thought of a product of capitalism, there are more interesting ways that IT can be used and applied. Technology can be used to reflect humanity, just as humanity is reflected in technology. Whilst capital is important, there are other subjects that are more interesting. I think I would like to read an IT business thriller about cyber security, as opposed to one about a business that has found a new way to sell engine monitoring apps.

To conclude, these two novels were fun. They were also informative without being overly didactic. Although IT business thriller books is not my favourite genre, I can say that I enjoyed reading them. I’m more a fan of Victorian romances.

Epilogue

In 2004, I was working as a Software Engineer in a small company that designed and manufactured educational equipment used to teach the principles of electrical engineering and computing. 

One day in April, the manager director bounded into the office where I worked.

“We’re selling our e-learning division! This means that we won’t be able to sell our flagship learning management system anymore. We need to find a solution. We had been working on an earlier project, but that didn’t work out. So, we need you to head up the development of a new learning management system”.

That new learning management system was given an internal codename. It wasn’t very original. 

We called it Project Phoenix.

References

Kim, G. et al. (2014) The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. 1st edition. Place of publication not identified: IT Revolution Press.

Kim, G. (2019) The Unicorn Project. IT Revolution Press.