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?
Good to have clean code for less headaches. That effort you put in pays off for you and your customers handsomely. If you struggle with quality, start on your journey to improving. Get yourself a plan to improve.
A few years ago I was lucky enough to work with Steve Freeman. Steve is the Gordon Ramsey of Software Development. If you have a badly formed code base, expect to hear about it. Steve worked with the graduate, Mark, on the team to “refactor”* some code. They created tests that clarified the intent of the code. Most impressive to me was that they reduced the size of the code base by 80%. Imagine you are editing a 200 page book with random duplication. Steve and Mark’s work reduced that to 40 pages and removed the unnecessary duplication. Everything was where it should be, and you only had to find something once rather than find a random number of instances. (Note: Some teams print off the code they delete and put it in a “book of dead code”) This was vital work as we were about to make significant…
The online IDE Cloud 9 is just awesome. It is amongst a number of online IDEs out there, of which I think it is the best. With Microsoft also making .NET opensource and available on all platforms I can also see myself doing .NET development on this as well. Yes I know there is Monaco from Microsoft but that is still immature and yes there is Mono on linux as well but that requires fiddling about.
It uses bash to run multiple commands, one for the Tyepscript compiler and then followed by the mocha test runner. Prior to running these command it deletes the previous .js file and if tsc fails the old file is still there and the test runner will pick that up still and we rather not have that.
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.
Some books on lean and agile software development. The list is still in development. I’ve read all of these books and will not place books here that I have not read. Some books resonate more than others, but still don’t expect instant recall of all the detail – rather the key ideas and concepts and then drive into the detail if required.
You’ll find some books are relevant to more than one section, so they will be repeated in the sections in which they have relevance.
Here’s the poll and feel free to enter your comments as well.
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.