Heuristics For Determining Correct Level Of Abstraction

[Edwin_Schasteen]

Hi Everyone,

If you discover some heuristics that helped you to determine a better level of abstraction while coding, can you
place the heuristic here? Also maybe a description of the situation to which the heuristic applied?

To start the conversation, I attached the following image of my psuedocode from Section 2 Lecture 29 “Psuedocode Programming”. I feel like my comments in the TODO on line 72 in the code below is going into too much detail, and that I should not include it there…I feel that if I omit line 72, that I would be at the “correct” level of abstraction, whatever that is. On the other hand, I feel like that detail makes sense, and that I am going to have to implement it
anyway. So I am just stuck on trying to figure out how to determine when I am going into too much detail, and when I am not. I suppose this is subjective, but I was hoping for some rules of thumb or some thoughts if this interesting to anyone. If you have any references to books, or articles, that would be okay too!

Of course, I will post any heuristics I find useful here as well.

Thanks!

While working as a professional tutor, I found that a couple of students who were struggling with the concept
of variables in algebra were helped by a brief explanation of how ambiguity in variables is what makes variables useful, but also is what makes them confusing! A natural thought might be that more things a variable can represent, that is the more ambiguous the variable is, the less details we actually know about a particular variable and the less we know…but this actually not the case! Example: if we were to try to get a grip of what the human brain does by looking at the detailed movement of every single electron, atom, molecule in every neuron in the brain, we would have a low level of ambiguity, but would also be quite confused, where as if we abstract those details away in admittedly not perfect models of brain function of a given region, we can make some useful predictions. So in this case, more abstraction leads to better understanding. What I have noticed with my own learning, is that some concepts seem to have an optimal level of ambiguity, or level of abstraction, where the nature of the thing almost seems trivial, simple, and uninteresting, but that straying from that level of ambiguity just a little in either direction (more or less ambiguous) increases complexity but also resolution of the concept. This is all admittedly abstract, but this is a work in progress that I hope will become more refined over time.

Think “Level of Abstraction” = “Level of Ambiguity” in two JPEG files below, and thiat “Optimal Level of Abstraction” = “Optimal Level of Ambiguity” = “Optimal Number of distinguishable things or functions an object can be or do”. I am not sure if this makes sense in the context of abstraction as is used here in object oriented programming.

[Rob]

Hi @Edwin_Schasteen, interesting topic for your post.

I think you hit the nail on the head when you mentioned about it being subjective. In my opinion, and it is only that, a personal opinion, I like comments, and I like white space, and I know that I can chuck a whole lot of them in and that when all of the code gets compiled it will all get ignored - so no real harm done.

If you are working on a project on your own, I would say go with whatever makes you feel happy/confident, if you like a lot of detail, add a lot of detail, if you don’t, don’t add so much.

TODOs are very useful in Visual Studio as you will have already noticed, you can also add other comment types too, for example there is a HACK one and so on, but you can customise this and then filter a pane to display them.

I am probably more verbose in my code commenting that a lot of other people, there is an argument for people being able to just look at a method and see exactly what it does without further instruction. That’s a nice concept and in a perfect world may work very well. I come from a systems development background with a team that changed frequently, with a huge variety of applications to maintain it could be challenging for new members of the team to get to grips with things, so when ever I wrote code I added comments which kinda made it dummy proof, as we would have people of all abilities…

If you are working with someone else, or in a team, then it’s probably worth having a discussion with them and agreeing on a fairly relaxed, informal and lightweight way forward. If you are writing half a page of notes in a TODO, maybe there is a more appropriate/useful place to put that, or maybe that should be something that is discussed with a team member and worked out in collaboration before going much further.

I would lean towards personal preference, but would add that consistency is key, these discussions often also lead into naming conventions and so on… for example, I know people that will do this for a class level (member) variable;

m_intCounter
_intCounter
m_counter
_counter

I have my own personal preference, but honestly, if I were looking at someone else’s code I don’t really care that much, but what I don’t want to see is inconsistency, e.g. in one class we go one way, in another a different way - that just makes things harder for all concerned. If I pick up someone else’s code, I always try to follow suit in the way that they have already written it - courtesy I suppose - and I would do the same with comments too.

Do what feels right for you

[OboShape]

Nice topic

I’m a bit old skool from when i started coding from a pre-windows era, I’ve carried on certain processes and practices that help me, like Rob said, it can be very personal and subjective.

for a beginning i like fleshing some flow chart things out on paper with one line per thing to do from a high abstraction level.
then that forms the generalisation basis, and just break each one down as i go along.

again, its a personal process, helps me to break sections down.

just my 2p into the mix.

[ben]

This topic looks really interesting, I have bookmarked it to give it my full attention over the weekend. I’m also sure that @sampattuzzi will be interested.

[Edwin_Schasteen]

Hi @Rob,

Thank you for your insights! I can see how when working on teams with varying level of talents you would have to be
especially careful in crafting comments and documentation, and definitely can see how inconsistency could create major issues.

Have you ever been in a situation while working on a relatively large team where a change in convention or process is thought of that may result in improved system performance, and that change was necessary, but that implementing that change ran the risk of introducing inconsistency within the code across a set of projects?

I’ve encountered situations like this over the last couple of years during redesign and implementation of our developmental math courses, and just this last semester, a complete math curriculum redesign with sweeping structure and program changes across all math courses taught at our institution. Since complexity of our system seems to be part of the problem, I am wondering if some of the practices being taught in this course, such as a suitable version of abstraction and refactoring, could be applied to curriculum redesign processes?

@OboShape

Thank you for the flow chart idea! That seems like a good way to not only keep track of all the parts, but also to make sure that changes are done somewhat incrementally. I have been playing around with an opensource software development environment called
PWCT 1.9 (Art)
that actually allows one to build applications in C, C#, Python, and Harbour directly from a kind of flowchart in a way very similar to the process you describe.

@ben

Thank you for your time Ben! I look forward to any ideas you and Sam may have on this topic!

[Rob]

Hi @Edwin_Schasteen, you’re more than welcome.

I have been in the past involved in a few yes, not games related, but taking web based applications from ASP to .Net many years ago, and then with other larger .Net applications, various updates to the functionality. Team size was only around 10 developers and they weren’t all working on the same project, at anyone time it was no more than 4.

The issue did still apply though, in that we would all have our own way of writing code. We agreed to remain consistent with the existing way the code was written, unless, we were swapping out an entire chunk of functionality. If it was something that could be isolated and was independent then we would rewrite that in a different (better?) way, the rules for following the previous approach could be broken in these cases. Often it would be perhaps someone updating web services, these would sit outside of the web application, but were part of the same solution, they could be treated however as a separate mini-project if you will.

Expecting everyone to agree on a set of standards, when there isn’t already a set of standards in place across a team I think can consume an enormous amount of time, everyone will have their opinion on the best way to do things, and that’s not to say that any of those ways are wrong, but if you are seeking to consolidate an approach so that everyone does things the same - good luck If you have the luxury of creating a new team, you have the opportunity to put standards and best practices in place on day one, these can grow over time and adapt, but obviously if they receive significant changes then all of the previous work the team has done no long meet those standards!

With regards to your abstraction and refactoring question specifically, I would say yes, I don’t see why not. If the system you speak of is very complex it may be better to take small steps with it of course, maybe rather than aiming for the “perfect” rewrite initially, just make smaller changes that offer benefit but without the whole thing becoming a tangled mess. I have been through a few situations where I didn’t do that, and ended up hating the project after a few months and just got utterly lost in it. One project in particular never got completely finished, so half of it (user end) was left in ASP and the admin side got upgraded to .Net - the reason for this was time/priority changes, but I would say it got left in more of a mess!

New applications I think are always easier, and as @OboShape says, you can flesh things out nicely on paper/white boards. I’m a big fan of user stories too.

Any-hoo - wearing my keys out here