Computer Module Project Memo
BY AMY PONDOLFINO
IDT 507
As a programmer, I’ve often joked that users don’t know what they want, but they do know what they don’t want after you give it to them. No matter how experienced, they are usually not good at writing software specifications. Yet, when the user sits down and interacts intuitively with the software, a world of insight is gained.
In my podcast, I lightly explore the history of user testing in software development, and the feedback loop between end-users and developers. Agile project management, and the advantages it affords, are compared in brief to Waterfall management techniques.
If you haven't already followed the links at the top of this page, you can listen to the podcast on SoundCloud: https://soundcloud.com/user-929168975/software-development-and-user-tester-programmers
Agile project management starts with the assumption that not everything about the final product is known and that requirements will change. This technique affords maximum adaptability to a changing marketplace and emerging technologies. Work is divided into short two to four week iterations, during which (ideally) a small subset of features are worked on to completion. The affordance this provides is less ‘technical debt’ – meaning fewer features that were started but not quite finished. Testers are included on the development team through out. This means that errors are identified earlier in the process when they are less expensive to remedy.
Waterfall management is more traditional and having managers and staff feel comfortable with the process is an affordance in and of itself. A project is carefully documented before it is started, complete with set funding and release dates. This is perfect when the requirements are known and are not expected to change, and affords managers a great deal of control over the work effort. All features are fully developed over a long period, after which the product is tested and any necessary changes made before the customer receives the product. I don’t know if that aspect affords anything, at least concerning software development – other than it’s easily marked off on various charts.
There is a third technique, only touched on in my podcast, called collaborative software development. In this model, many users voluntarily work on a large body of free and open source software. This model has been incredibly successful, although it wouldn’t be possible without widespread use of the internet. My favorite software development tool, Eclipse, was developed and is continuing to be developed, using this model. Because many are reviewing changes as they come out, bugs are quickly reported, often with a suggestion for how to fix it included. This approach is user driven, and affords end users ultimate creativity in adapting software to suit their needs. The end-product is generally feature rich and well tested.
There are drawbacks to all these methods. Few are the organizations that are willing to forgo their project schedules due to a focus on cost and time constraints, so it is very difficult to fully embrace Agile. Generally, compromises are made and not all Agile principles are adhered to. Agile development also depends very heavily on the ability of the development team to work together efficiently and independently. Ease of use is not afforded by this technique.
Waterfall management techniques are almost completely inflexible, which makes them poorly suited to the fast-paced technology sector. A project, once started, cannot easily embrace a new and different technology. However, the greatest problem with this approach is how testing is put off until after the coding is complete. Fixing an error at that late stage will be difficult and likely to introduce new errors. This is particularly true in software development, where code for various features is inter-mingled and inter-dependent.
Despite its successes, collaborative software development also has its draw-backs. This method relies on the availability of a large pool of enthusiastic programmers that can’t wait to fix issues and code new features in their spare time. Needless to say, it’s difficult to start a new project that way. Software that is popularly used by programmers can be a good candidate for an open source project.
I created my podcast using Audacity, which worked as advertised, although I did have to slog through some tutorials to figure out how to use it. It was a little time consuming to splice my various recordings together, but straight forward enough. Were I to take up podcasting regularly, I would absolutely have to get a nice microphone to improve sound quality. Finding a way to embed the podcast in a blog was more difficult than I anticipated, as web browsers have not all embraced HTML5 and audio files are less universally supported than video. I started a blog on Blogger, uploaded a copy of my podcast to Google Drive and embedded it in an audio player at the top of my blog, based on recommendations I found online. None of the browsers I have (Firefox, Chrome, Explorer, Edge) could play the embedded audio so I uploaded a copy of my podcast to SoundCloud and included a link to it as a backup. I was finally able to embed the audio player by uploading my .mp3 file to OpenDrive, which provided code to embed the audio, and it worked!
My intended audience are my fellow computer programmers, information technology managers and students of information technology, who would like to better understand overall project management techniques. They might also find the historical aspects interesting.
My two previous posts include the project references and the podcast script.