Tag Archives: programming

Is the Nassi-Schneidermann Still Used

Thinking back to when I was learning programming in the 1980’s the instructors taught us about program creation by a visualization technique called Nassi-Schneidermann diagrams. Here’s a nice summary from breezetree.com.

I thought it was an excellent way to visualize program flow for a novice. It’s only needed for a short time and learners can quickly move to pseudo code. Most programmers can move beyond pseudo code as well.

Knowing the importance of visualization in the Kanban Method, I wonder if new students to programming are being taught via the Nassi-Schneidermann?

Can we use it to increase engagement with the people we are delivering software to?  I suggest we can.  I’ll leave you with this example from breezetree.com and ask can you understand the flow of the program?

nassi-shneiderman-diagram

 

Advertisements

Ok to be Mediocre, Ok to want to Improve

Last week I posted the following to twitter, somewhat inspired by Margaret Heffernan’s TED Talk on the Pecking Order and also by my own experiences in being interviewed and interviewing applicants for jobs (some ideas captured here in a earlier post/rant on broader dysfunctions).

Elitistism preventing New Hires

Some questions in interviews are valid but when it takes a demeaning, condescending tone – that’s when you know you’re in trouble.

Friend and colleague, Ryan Musgrave, in response, posted this video from Jacob Kaplan-Mosson (a self confessed mediorce programmer), which is related to the subject.  Those 10x programmers that some dream of hiring just aren’t as thick on the ground.  In fact hiring them could also reduce the through put of your team (read Five Dysfunctions of a Team to get a real life account of this).

We mostly fall in the middle for talent

We mostly fall in the middle for talent

We mostly fall in the middle of a normal distribution as the video explains.  It’s time to stop dreaming of hiring superstars and look to develop the skills of high potential applicants.  They needn’t know the Agile Principles off by heart or recite every little bit of Object Oriented doctrine that could easily be memorized anyway.

Look to test applicants on more meaningful questions about how they deal with technical problems, how they learn, how they deal with people problems.  Again these need not be perfect answers but should give you a feeling of potentiality.  Ultimately a good applicant wants to develop mastery in what they do.  Think of questions that will give you clues to this and give you a feeling of genuineness.

Ultimately Values, Principles and Philosophy should align best they can.  If your own Vision is strong then finding those who want to follow should not be hard.  As those looking to hire, perhaps starting there and looking inwards is the place to start.

Those feeling belittled by by the superstar programmer, take solace, also look inward and look to get the best out of yourself.  If your a superstar programmer and maybe not as generous to others in the team, you can improve as well by helping others to improve technically.  Collaboration is hard but does reap many benefits personally and for others and for the bottom line.


Retro Games from the 80’s

A reminiscence. Remember the basic graphics and sound of those early games. Here’s a simple game called Gridder I cloned from a Commodore 64 game called Supergridder. It’s written in C.  I was infatuated with this simple game of the C64 and thought it an interesting project to write my version of the game as a project.

Screen 2 of Gridder

Screen 2 of Gridder

To run it you will need a Dos emulator like DosBox. You will also need to slow the CPU speed down in the emulator. In dosbox you can use Ctrl-F11 to decrease the CPU speed.  Use the mount command in the emulator to access the downloaded game on your local hard drive e.g. mount c c:\temp.

When the game was written it worked on much slower hardware. It’s quite hard to play when it’s too fast.  If you have an ancient dos machine it will probably still run.

Game Play

The idea of the game is to fill in the borders of the rectangles to cause a rectangle to be filled in. At the same time the player needs to stay out of sight of the two bugs. If you are caught you lose a life but you can put a temporary gap between you and the bug by pressing the F1 key. On completion of a screen you move onto another screen with a different layout. You score by filling in rectangles. Complete a screen fast and score a bonus with the time left on the countdown timer added to your score.

Enjoy


Put the Analyst into Analyst/Programmer

I used to say for over 15 years, put the Analyst back into Analyst/Programmer. This was when many jobs where advertised as Analyst/Programmer, but the Programmer never really did any meaningful analysis. It was mainly confined to the act of writing code not so much about the understanding of requirements.

The reason it fell into disuse is probably correct when you look at the traditional ways software was produced.  Another reason could be the cognitive load required between swapping out of coding and understanding requirements. This a more like an excuse rather than looking for causes.

I’ve now come to say put the Analyst into Analyst/Programmer.  It was never really there in the first place.  A programmer can and should have valued input from the beginning of the software production process.  That does also mean being a nice person and maybe strengthening into areas not so familiar like talking to customers – it’s a communication process as much as a technical process 😉

Inspired by this talk from Martin Fowler this year that I feel aligns with this ideal, I’ve included the following call to arms that I now start my Agile Programming course with, which is to be released soon.  I hope to sharpen it up a bit more.  You can have input into it if you like.  Here’s a start:

As programmers we are more than just code monkeys​. We are motivated to create value for our customer​, so we should be on board with everything including:​

  • Being able to speak to our customers to learn the domain we are working in​
  • Being able to seek clarification from anyone​ be it Business Analysts, Customers, Product Owners, Testers or anyone else
  • To question anything that we have concerns about​
  • Expect to have a meaningful input into understanding requirements​
  • Expect to inject innovation and have it considered

Over to you.  Admittedly there is some work to do to unravel decades of silo based work practices.


Rubber Ducking – Talk to Yourself

I sometimes find myself talking to myself to work through a problem.   It annoys me when I was accused of being mad.  But what needs to be realized that this is a great and valid way to work through an issue when you don’t have access to someone else.

Often the process of talking through a problem causes a solution to present itself.  The Pragmatic Programmers recommend it here via wikipedia.  I highly recommend their book The Pragmatic Programmer which I’ve had on my bookshelf since 2003.

Talk to someone else when you can that works well.  When you can’t, have a chat to that Rubber Ducky and explain to anyone who questions what you are doing.  Involve them if they are interested.

Remember you’re not mad – your being very resourceful.  In fact apply this to any problem solving activity.