Tag: software engineering

Posted on

Perception is everything (when defects are not defects)

I worked on a project in the early 2000s where the client didn’t like to be told that we had x hundred defects in our backlog. To address the negative connotation of the tickets being called “defects” we renamed them System Investigation Requests or as we called them day to day “SIRs” (a quick Google will tell you that this is not not a unique name for defect tickets, but in 25+ years something I’ve only come across a couple of times, and only for projects with this same client).

The truth was was the majority of tickets were actually genuine defects but there were also some requests for refactoring, TODO follow-ups, potential issues that should be investigated that could lead to identifying a defect, or just areas for improvement.

it’s interesting how we perceive things either positively or negatively just based on name, The client was more comfortable knowing these issues were vaguely called SIRs, but if I was the client I would have thought “I know these are defects, you’ve just renamed them” but in this case they were happy calling them something else.

Posted on

Previous posts about AI Models and Code Generation

If you browse online software development communities, questions from new developers about AI replacing the need for developers are asked almost daily.

Here’s a couple of my past posts on this topic from 2023 and 2022 which I feel still hold true:

No, AI models will not replace programmers any time soon
Generating code is easy; Understanding customer requirements is hard. (Or, why AI generated code is still decades away)
Posted on

As an industry we still don’t know how to effectively transfer ‘experience’ to new developers

New developers start their careers with a limited grasp of the ‘what’, the basics of how to write code in a given language and tech stack, but the deeper understanding of the ‘why’ and how to evaluate potential solutions and pick the most effective solution given known constraints comes much later with experience.

Experienced developers have knowledge of what they’ve seen work and not work from past development projects and can use this knowledge to make educated decisions. Given any problem, having seen multiple solutions applied on past projects allows you to draw from that knowledge of seeing what has worked and not worked and evaluate what solution is the better option when you see this problem again (or something similar).

Experience and knowledge is hard to pass on from one developer to the next. Programming techniques like iteration and conditional statements can be taught and easily learned, but an appreciation of why solution A is more effective than B is harder to convey, usually because the reasons why one solution is better depends on the context and an understanding of the current constraints that you need to work with. Being able to identify what’s important and what is not is a skill that more experienced developers develop over time, but it’s hard to teach.

Experienced developers add obvious value to any project or team, they provide leadership and the benefit of being able to make informed decisions based on their prior experience that lead to better outcomes for the business with a higher degree of certainty (compared to randomly picking a possible solution without knowing if it’s feasible or the most effective option or not).

The problem we have as an industry is that we still haven’t worked out an effective approach for conveying this experience to other new developers. You can gain experience by putting in the time and effort by working on a variety of different software development projects, but there doesn’t appear to be any easy fasttrack approach to package this information and hand to another developer. Can software development experience be ‘knowledge transferred’ to another developer? Maybe not. Maybe you just have to invest the time to gain experience the hard way.

Misunderstanding or under valuing the experience that an experienced developer brings to a team is a common mistake of someone who does not fully appreciate the complexity of software development. All developers are not equal, and one developer cannot be equally exchanged for another. If we can find an effective approach to easily fastrack the passing of experience from one developer to another, this would massively accelerate the growth of new developers, but maybe the reality is experience just has to be gained the hard way.

Posted on

Getting started with small team software development projects at school

Interesting question I saw asked on Reddit recently – “what tips do you have for getting started on a software development project with a small team for school?”

The interesting thing about this question is that the recommendations are not much different from practices and approaches you would use for any ‘real world’ development project with a team.

Here’s some things I would recommend:

  • Host a shared repo somewhere, for example Github or GitLab. Watch some intro videos on how to use git, how to clone a repo, how to commit and pull changes
  • Establish who on the team is working on what, even if it’s just a list of features and then you divide them between the team. This sounds obvious but it will avoid confusion and wasted effort from more than one developer on the team working on the same feature.
  • Think about the structure of the app and how you will be implementing different features, Worst case: if you have a single Class with all your logic in a main() method, how are multiple developers going to work on this at the same time (hint: this will make things very difficult)
  • If there is a basic skeleton of the app put in place at the start with placeholder empty methods with ‘feature A goes here’, that will make is easier for each developer to go off and work on their part. Even better if using an OO language, thing about your Classes that will represent your solution.
  • Encourage everyone on the team to commit their parts back to the repo often, daily, if not more often. You don’t want devs on your team to go away for days and then commit a ton of code in one go. That will lead to unpleasant surprises
  • Encourage use of unit tests, they’ll help not only you to understand that your code is working, but allow the whole team to run tests for the parts they’re not working on and confirm that the addition of their changes has not broken something else in the system.
  • Think about how you’re going to build your code as a whole, and how/where does it get deployed?
  • How are you going to manage your library dependencies? Set up the project at the start using Maven or Gradle. It will make it easier for everyone to pull in the right libraries and the right versions.

For a small team and for a school project this is a good start.

Proudly powered by WordPress