Innovation Fridays, Software Development

Learn C# – Principles II

2p4iLast week, I posted the first part of my Learn C# principles discussion. There I covered those principles which I believe would be less subjective and more widely held. This week, I am delving into some more personal principles which I find have improved my code greatly. However, to begin our discussion this week, I will speak on a concept that I believe many will again agree on.

One thing that almost every new programmer should know is that many problems that they will encounter have already been solved. Of course , as with any system with multiple solutions, some are better than others. The best of these have been codified into a series of Design Patterns produced by the “Gang of Four“. To be completely honest, I wished that I had found out about these far earlier than I did as they would have saved me a lot of frustration in creating some of these patterns for myself. But patterns like the Adapter, or the Facade I find myself using quite frequently. But more importantly they changed how I look at the problems that I am trying to solve. I spend more time thinking of the responsibilities, than of the methods. As a result I have gotten better about following the Single Responsibility Principle, mentioned last week.

In general, I believe that most developers would agree that these patterns are helpful, though some are more esoteric than others. Now seeing as I am instructing the C# course, I thought it would be best to reveal any potential hidden biases I have so that the students at least have a hope of separating what I personally believe to be good, from what is generally held to be good. This is most likely an over-abundance of caution but I truly wish to do right by those who have sought my instruction on the subject.

The first place where I recognized that I might be slightly biases was in my experience with Python. Python is a wonderful language to pick-up and a very powerful, albeit not particularly performant. But while I was learning to speak Python, I came across a peculiar text which espoused some principles for software development that I hold to this day. The text is called the Zen of Python, and goes like this:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
-Tim Peters

Admittedly this may require some additional explanation. I have found that it is easiest to look at in terms of paired ideas. For example, take lines 2 through 7, which cover such pairs as Explicit/Implicit, Simple/Complex, and Sparse/Dense. All of these are talking about how our code ought to read. Referring back to the text, it is better to Explicitly state what a function does, than to execute implicitly. This is idea of explicit effects is not merely held for python but can also be heard as have no “side-effects”. That is one possible interpretation of this line. But what makes the line so powerful is that it embodies the principle rather than the specific case. Another instance where the principle applied is repeated within the text itself: “Errors should never pass silently. Unless explicitly silenced.”

So, as I have attempted to express there are a couple of larger principles explained nicely here with more specific guidelines towards their implementation. The easiest to see is that a developer ought to be expressive in their code, this theme runs throughout the poem. The second theme is that a developer ought to be pragmatic, which is somewhat shown in Practicality beats Purity, and in “Never is often better than right now.” It is another way of showing YAGNI, or “you aren’t gonna need it”. These two are often held in a delicate tension, on one hand there is the pragmatic solution: Sparse is better than dense; but this is contrasted immediately with the Expressive side, Readability Counts.

Python has been gifted with some humorous supporters throughout the years, including Time Peters, who wrote the Zen. I have found the kernels of truth laid underneath the clever words in several instances of quips about Python. I would heartily encourage every developer to read through them and make their own judgement. But if I can I would draw attention one other Python quip, which I find very humorous and also truthful.

This quip is called “Python vs. Perl according to Yoda” and it goes something like this:

Subject: Python versus Perl: A humorous look

From: larry (funkster@midwinter.com)

Date: 10 Jul 1999 01:45:07 -0700

This has been percolating in the back of my mind for a while.

It's a scene from _The Empire Strikes Back_ reinterpreted to serve

a valuable moral lesson for aspiring programmers.

--

EXTERIOR: DAGOBAH -- DAY

  With Yoda strapped to his back, Luke climbs up one of

  the many thick vines that grow in the swamp until he

  reaches the Dagobah statistics lab. Panting heavily, he

  continues his exercises -- grepping, installing new

  packages, logging in as root, and writing replacements for

  two-year-old shell scripts in Python.

YODA: Code! Yes. A programmer's strength flows from code

  maintainability. But beware of Perl. Terse syntax... more

  than one way to do it... default variables. The dark side

  of code maintainability are they. Easily they flow, quick

  to join you when code you write. If once you start down the

  dark path, forever will it dominate your destiny, consume

  you it will.

LUKE: Is Perl better than Python?

YODA: No... no... no. Quicker, easier, more seductive.

LUKE: But how will I know why Python is better than Perl?

YODA: You will know. When your code you try to read six months

  from now.

To get to the meat of it, Perl, which came before Python, encouraged some bad programming habits, like default variables and others which made it difficult to understand the code. Referring back to the Zen, it was not very expressive, since the syntax is terse.Additionally the “true path” of execution is difficult to determine since one cannot know how code will execute without some significant additional context, like the default variable values. And sadly, as Yoda describes, if a programmer falls into these traps in the early stage of a project, it becomes much more difficult to come back, if not completely impossible.

To cap all this, the script offers a humorous test to determine whether or not you are following good patterns. If you can read your code in six months and know what you were trying to do, then perhaps you have done well. This sits along a similar vein with the Zen’s “If the implementation is easy to explain…”. And I find it gratifying to find the self-consistency of the Python supporters in this. I am happy for both examples in order to see the many facets of the delicate balance between expressive and pragmatic code.

This concludes the principles which I attempt to adhere to in my coding, and the ones which I will be utilizing in the workshop.As I had said before, I am trying to teach the principles first to help the future coding and learning to become easier. Looking back, I realize that some of this desire to teach principles first comes from some bad experiences that I had during my early college development days. As Yoda says, “If once you start down the dark path, forever will it dominate your destiny…” . I am hoping to same the participants this agony, and frustration.

This basically covers the ideals that I hold for my software development and my general understanding of them. As always I thank you for your time, and hope that you learned something! Let me know in the comments!

* – The C# logo was created by DevStickers

//Edits//
11JUN2016 – SpellChecking and Minor Grammar/Readability Refactor
Standard
Innovation Fridays, Software Development

Learn C# – Principles I

2p4iLast week, I began introducing the Learn C# Workshop that I was asked to lead by the ATS* Team for our Innovation Fridays. In this post, I had planned to share all of the principles which I espoused to the group during our first meeting. However upon drafting this post out, I realized that I have a tendency to be long-winded. So to avoid putting too much information into a single post, I am splitting the Principles into two parts. In this part, I will discuss why I am starting the workshop with principles rather than basic Object Oriented Programming examples.

Then I will move on to specific principles, most of which my employer also expresses appreciation of. My next post, will cover my intention to use some of the Gang of Four Design Patterns, and will also cover some expressions of good software development principles which I believe are more personal, and not necessarily held by my employer in general. I thank you for your patience, and will now get on with explaining myself. Let us start with why I am so focused on principles!

It is my strong belief that, when learning, it is wise to start with guiding principles. Naturally, the student will not understand the full application of these principles at the beginning, but by laying them out at the beginning, and then re-visiting them during the course of learning, the students will begin to understand the connections. As a result of this belief, I chose to start my C# workshop on good software development principles. I chiefly did this to help the group not “develop itself into a hole”, but also to make it easier for them to understand the proper use of the language as they develop. My goal has always been that the participants would leave not with a “duct-tape solution” but with a more polished understanding and grasp, so that if and when they begin working on real C# projects they would be able to understand and manipulate the code with ease, rather than grinding their teeth in frustration while they try to “just get the system to work”.

In this approach, my principles for development and for the course are the same. I choose to Start with the End in Mind,hereafter SEM. To simply begin a journey quickly, is not so good. It is far better to move in the direction of your journey’s end from the beginning rather than discovering later you have set out in the wrong way, and must retrace your steps. Even if your beginning is a little delayed, it is still wiser to move only once, rather than twice when an error was made.

I find that tied to this idea is the process of Test Driven Development, hereafter TDD. Admittedly, everyone that I know, who has tried this method, attests to its difficulty. Even I have had trouble with it. However I know that it is also one of the best applications of SEM in software development.

TDD is the process whereby one first writes a failing Unit Test, and then the code to make it pass. And then cycles back to write another failing Unit Test. This is intended to be a rapid cycling. The preceived difficulty is usually due to most people’s tendency to think of solving a problem from the top down. We often feel that instead of a fast loop that the loop is slow.

But what we lose in mental comfort, we gain in design. In TDD, one is forced to think about how one will test that their function worked from the beginning. This has many benefits, from avoiding unnecessary methods, and simplified designs, to encouraging the developer to separate responsibilities more finely and into more testable chunks. So even though TDD is difficult, I believe it is worth the trade-off. Further for beginners, TDD will force them to think about what effects they want a function to have, and how to verify that before they become lost in a tangled mess of code.

The next principle that I am choosing to espouse is SOLID. It also so happens that my company generally supports SOLID, though it has not been evenly applied to all our software. I have found that within SOLID that there are really three principles that most improve one’s design if followed. These are the S,I and D components.

S stands for the Single Responsibility Principle, which succinctly put, means that one and only one potential change in the software’s specifications should change a given class* [taken from Wikipedia]. This would means that a class’ responsibility should be fairly specific. For example, a Controller ought not be changed when the UI color changes, or even the UI color scheme. Now as silly as this might sound, I have written software that did not adhere to this principle and it was very difficult to maintain, much less to work with. I have found that in general that where the Single Responsibility Principle is not followed, spaghetti code abounds.

The I stands for the Interface Segregation Principle, and again borrowing from Wikipedia’s synopsis, it implies that “Many client-specific interfaces are better than one general purpose interface”. This principle is heavily tied, in practice, to D, which stands for the Dependency Injection Principle, or DIP for short.

DIP suggests that one ought to inject the dependencies of a component into it, rather that providing the component the ability to create concrete instances of it. For an example, following DIP, a FileFormater, would be injected not only with the data to format for writing, but also with the Access to the File System, rather than just creating that access itself.

Practically speaking, applying these two principles allows for software to be resilient to changes outside its scope, and it improves its test-ability. If a class depends on Interfaces rather than concrete instances, it is easier to test, and if the was some responsibility is handled changes, but not the interface, then the class in question does not need to change!

In the instance of our FileFormatter example, if the File System Access is provided by an IFileSystem interface, the FileFormatter needn’t care if the FileSystem writes a directly to a binary dump file, or a .txt with ASCII formatting, or if it translated every input character, in format, into Mandarin Chinese. Just as long as the Interface is implemented, providing the necessary functionality, the FileFormatter could be left alone, while the FileSystem Layer can change without concern for the FileFormatter, and vice versa.

Now to tie these principles to back to TDD, there are several ways to provide Mock implementations of Interfaces. As a result, depending on Interfaces allows use to test at a much deeper level. And for objects that might be more difficult to wield, either for being very large, or difficult to instantiate, or because it touches the system environment, like our FileSystem example. By separating our functionality, we can test components independent of their implementation.

Naturally this reduction of real components, means that our tests are less susceptible to the oddities of a particular class. Further, only the tests on a given class change with that class. If we do not rely on Interfaces, then when a given class changes, the tests for itself, and any class that depend on it might also need to be updated. I believe that developers generally refer to this as tight coupling, which highly undesirable.

So, I hope that this post has helped to explain my rational on Principles as a starting point, as well as some of the more common Principles which I hold to be true. Overall I feel this covers a bit more that half of truly good software development. Next week, it is my plan to cover the remainder, including some principles which more uniquely my own. So what do you think of this post length? Do you feel I went into enough depth, or perhaps that I should have posted the whole set? Please let me know in the comments! Thank you for your time, and until next we meet, be blessed!

*ATS = Automated Test Scripting

* Paraphrased from Wikipedia, which phrased it very well.

* – The C# logo was created by DevStickers

//Edits//
11JUN2016 – Spell-checking and Minor Grammar, Readability Refactor
Standard
Innovation Fridays, Software Development

Innovation Fridays – Learn C#

2p4iInternally, my company has experienced a push to get ‘Innovation Fridays’ started up again. Every month developers are given a 4 hour period to pursue various projects or learning. For this block of time, the Automated Test Scripting team, ATS for short had been interested in learning how to write and use C#. Given my familiarity with the Team, and my knowledge of the language, they asked if I would be willing to lead a workshop on it. Naturally I couldn’t refuse such a request from friends, and moreover, I knew this would be a chance to strengthen my core on C#. As everyone knows, to teach something is to learn it far better than when you first were taught.

I figured that my workshop plan, while good, had some chinks in its armor and that it might also make interesting reading. So for the purpose of getting some additional insight and for the freedom of information I decided to post a series on my plans and activities relating to the workshop. So if you think of anything, please feel free to make suggestions in the comments.

Now before I start, I want to express that I have a good deal of experience in running workshops on a variety of topics, including some rather technical ones. I somehow got into doing this when I was in high school, wherein I would help teach Tae Kwon Do to kindergartens, while working on my black-belt and after. Further, while in College I was blessed with an A in Calculus-based Physics, and so was asked by an enrichment program to lead a Physics workshop, which I did every semester for perhaps 3 years or so, until I graduated.

I very much enjoyed the work, and was blessed with some help paying for school by it. Among the most enjoyable was creating questions and problems for the students to work on, especially in Mechanical Physics. However I found that for the majority, the workshop was not totally ideal, since it must keep pace with the class. And sadly, many students could not keep up with the class in the first place. This is perhaps the single biggest obstacle that I am working to overcome with my present workshop plan.

Overall, I am planning to follow the recommendations made by Josh Kaufman in his 20 Hours TED talk, which I have mentioned before. Naturally I think the four steps are very well suited for learning C#, so my workshops will generally be focused on one or perhaps at most two of these steps at a time.With any luck, I will run these for the next 6 months or so, and have our learning concluded by that time. However for the first workshop which occurred last Friday, most of our time was spent on step 2, or Learning Enough to Self-Correct, and on deciding on project infrastructure. For this discussion I will talk more about the project infrastructure, and perhaps will elaborate more on the learning portion at a later time.

Now, getting back to the obstacle I mentioned earlier. Everyone on the ATS team is at different levels of skill, which means each will need a different levels of instruction and will be able to accomplish different amounts in the same time. So to support the needs of the high-performing team members, while maintaining the approach-ability for those who need more guidance, I elected to pursue Project based learning as the workshop model. On this topic, I put the team size and project type to a vote. It was decided that, for the most part, everyone would pursue their own project.

As a result we have 6 teams, for 7 people. As to the projects they are covering, those are somewhat less varied as there are 4 different projects at the moment. They are as follows:

  1. A Sudoku Game application
  2. A Music Player
  3. A Rich-Text-Format Text Editor
  4. An internal Installation tool for our Company’s Software

Of course, you can see that each of these will have different technical challenges, but also each has some elements of similarity. For instance many of these will need File Access, and each will need some component of UI. As a result these projects cover a breadth of topics making them good candidates for learning C#, while still maintaining some common ground for group discussions. To make things easier on myself, I have had all the teams setup the following organization for their projects, so that we can work with others more easily.

Every Team project will have at least 4 separate Code Projects( the place where code is dropped in Visual Studios Solutions). These are the Infrastructure, the UI layer, and the test associated with both. By separating the Infrastructure from the UI, I am hoping to provide the necessary grounds for following better design principles. Of course with how small these projects will be, It may feel somewhat silly to have all this extra separation. But since the purpose of this workshop is not simply to write the Project and get it done, but is instead to learn how to write C# well, I think it is a fair trade-off.

If we are going to be working so that our project structures are similar, it would make sense to ensure we are all using the same tools. And sadly, since most of our participants are using personal laptops, they don’t have easy access to the Company WiFi, or the source-control servers, which means we needed another place to store our code. This way the projects could be shared between teams when the time came. For this I have selected Github, as I am familiar with it due to personal side projects, and because it would be free to access for all involved. All I would have to do would be to add the ATS team as contributors to the selected Repo.

gitkraken-social-iconFor those of you who are also familiar with Github, you should recognize that git is very Command Line heavy without a GUI. So to make the transition easier for the team, I had them all download GitKraken, which is my preferred GUI for Github. So far, this has seemed to make the process much easier. But I will know more when we next met about a month from now.

Lastly, no code project would be complete without an IDE. And for this we turned to Microsoft Visual Studios community edition. We have a mix of 2013 and 2015, since that is what the team members were able to find. I am hoping that this will not cause problems later on when the projects are viewed by other teams, but we shall cross that bridge when we come to it.

So during our first meeting, we covered all of the project set-up minutia, and some of the basic principles that I am hoping to pass on. I will share this in my next Innovation Friday post. These will likely include the various links that I used and other references that I find to be very useful! In the meantime, I would love to hear any suggestions or ideas you have! After all, I only had my experience and my gut to go on, and I am certain I might have overlooked some great opportunities!

* – The C# logo was created by DevStickers

* – The GitKraken Logo was borrowed from the GitKraken website.

//Edits//
11JUN2016 – Spell-checking and Minor Grammar/Readability refactor
Standard