One of the things I learned about software engineering is a project management style called Agile Project Management, which some characteristics include:
This is a style that is well suited to small groups with easy access to customers for small projects.
To dig a little deeper, the specific style of Agile Project Management that we activitely used in our assignments is called Issue Driven Project Management.
Issue Driven Project Management statisfies the characteristics listed previously regarding Agile Project Management while also having its own set of rules:
Looking at these rules, I think it is pretty easy to apply this style of project management in things that do not involve web applications. For example, if my friend and I wanted to develop a game heavily inspired by Flappy Bird, then applying Issue Driven Project Management would look something like this: Milestone 1 would deal with the visuals first, where you first settle on the “pipes” and the “bird”. In this Milestone, my friend would be assigned to the “pipes” and I would be assigned to the “bird” or vice versa. On Milestone 2, the person responsible for the “pipes” would not allow the “bird” to collide on to the “pipes”, and if it did, the game would end. The person responsible for the “bird” would have to figure out how to allow the player to move it, and maybe show some sort of score accumulation on the screen. If there was a hypothetical “customer” involved in this project, they could simply request things such as, “Oh, can the bird be a flying pig instead?” or “Change the sound when the bird passes through the pipe!”.
As the small-scale project continues development, you could see how Issue Driven Project Management simplifies things for the developer and for the customer.
Another thing I learned about software engineering is the ethics around it. Ethics are moral principles or values that define or direct us to the right, or wrong, choice. In the context of software engineering, my ICS 314 classmates and I discussed a case study surrounding a company decision where a new employee with only two years of experience got promoted to a manager role over another employee who has exceptional technical skills and leadership qualities, along with eight years of experience. One of the key differences between the employees is that the former is proficient with AI, a rapidly growing field in software engineering. For the company, it now becomes a question of how much you value AI in this current day and age.
The AI-proficient employee can potentially finish tasks a lot faster, but what if the AI they are using is not able to solve the problem they are asking it to do? In this case, the other employee with excellent technical skills would most likely be able to solve the problem.
An additional way to look at this situation is: what if the AI-proficient employee has better managerial skills than the skilled employee? I think it is important to consider that if the skilled employee has eight years of experience, then why have not they already been promoted to a manager role previously?
With that, I think an important part of ethics concerning software engineering is choosing how to navigate between the two sides of the same coin. Asking yourself questions such as: “Doing this good thing will also cause this bad thing to occur, is it worth it?” or “I do not like this task that was given to me, is there another way I can do it?”. And in the case of the company, they decided to choose AI, and not have an exceptional employee on a managerial role.