Advancing The Craft

There's been a lot of talk lately about 501 developers and the confusion as to who they are and what to do about it.  My understanding of the original intention of a 501 developer isn't just someone who leaves at 5:01, but someone who makes no advances in their craft.  The time is just a symbol that they do not advance under any condition for any reason.  I usually leave at the same time as I want to go home and spend time with my family.  My children have after school activities that they need to get to and I want to watch them play.  There's nothing wrong with that.

So what is a 501 developer then?  To me it is someone who doesn't love their job or care enough about it to try and learn more.  They make no attempt to advance their craft.  I spend only a little bit of my time each day to learn more.  I don't do it a lot, as I don't want to get burned out and become bored with the very thing that I love doing.

There are two main points that I'm trying to get across.  One is if you don't love your job, then maybe you should be looking for something else to do after 501.  If you do love you job then you not a 501 developer.  If you love your job then you are probably learning or reading blogs like this one already.  The second point is how much time should you spend learning about the craft?  Well, logically, the more you love your job then the more likely it is you'll spend time trying to learn it.  However, if you spend too much time trying to learn then you're probably getting burnt out.  I feel that it doesn't really matter how much time you spend as you will eventually find a balance.

If you don't love what you do, then you should spend some time trying to figure out what you love to do.  If you love what you do, then you already know what you need to do.  If you ever find yourself at the point of not trying to learn or you do not really care about your craft, then you need to do some self reflection and soul searching to find the answer to the question: Do you love this job?

Procedual Programming vs Object Oriented Programming - Part 3

This is a topic every developer must deal with at some point in their life. I broke this article down into several parts. The first part is about procedural programming, the second part is about object oriented programming, and the last part is the summary.

I've gone over the pros and cons for both procedural programming and object oriented programming over the last couple of days.  This part is basically a summary and an included story on why it is probably better to use OOP.

In the beginning, there was an email program that sent out statements to customers.  The application structure was a procedural program.  Basically, a list was returned with the customer name, account number.  Another procedure returned the email addresses for each account.  The last procedure was to create the report that is then saved to the hard disk to be attached to the email and then sent out.  There was a mistake made earlier in the application where the account ID had to be validated.  That validation function then timed out and it just returned the last used Account ID.

So just to make sure you understand everything, the program was going through each account and at a certain point earlier in the application the same account ID would be listed for each account.  Now this trickled down and when the application was building the report it was using the wrong account ID.  So essentially, almost everyone ended up with the same wrong report.  It had their names on it and account numbers, but the information was completely wrong.

Now the reason OOP can prevent this from happening is that the account ID would not be displayed outside of the objects' class and it would always be initialized with 0.  In procedural programming many variables are more public than they should be.  This really isn't a problem with procedural programming as it should've been initialized to 0 before it attempted to get the next one, but it does open you up to making these types of mistakes.  OOP hides variables better and initializes variables when a new object is created.  With procedural programming you can reset variables, but it creates more spaghetti looking code than is necessary.

In the end, unless the application is really small and your team is super small, you're probably better off using OOP.  However, if you don't understand OOP then I do recomend that you start off with some spikes before you start coding any production code.

Procedual Programming vs Object Oriented Programming - Part 2

This is a topic every developer must deal with at some point in their life. I broke this article down into several parts. The first part is about procedural programming, the second part is about object oriented programming, and the last part is the summary.

The Pros and Cons I found online were pretty standard for OOP.  There is one that is sort of contradictory.  Many people say it's easier to maintain and you can add or remove functionality faster.  Then they go onto say that it takes more development time to create an OOP application.  How can this be?  Well, it's true in that it takes more development time to get started (both design and creating the structure), but once that base structure has been completed it takes no time at all to add, remove, or alter functionality.

Let's say we have two car factories.  One factory is procedural programming.  They take this car and they add one thing at a time until it can drive off the lot.  It's not exactly fast, but it works.  Now the OOP factory is a new factory and you can't just start building cars.  You have to create an assembly line.  This takes some time and thought as you have to structure it correctly before you can start building cars.  Meanwhile the procedural programming factory has created 10 cars as the OOP factory hasn't even built one.  Once the OOP assembly line is completed; building cars becomes a snap and before you know it has built 20 cars while the procedural programming factory has only built 15.

The other thing I want to go over before I show you my list is that OOP enables you (the developer) to alter functionality with a lot less fear.  By this I mean that since everything is structured and the details are hidden, you don't have to worry about changing a detail that will alter everything else.

Pros

• Easy to maintain as in you can add, edit, and alter functionality with less fear.  (This is assuming you understand OOP)
• Reusability.
• Easier and faster to add additional features.
• Everything is structured and therefore, code is cleaner looking.  (No more 100+ line procedures)

Cons

• CPU intensive (Performance may be affected).
• Learning Curve (Not everyone can wrap their minds around OOP).
• Harder to follow along as abstraction and inheritance can get confusing.

Procedual Programming vs Object Oriented Programming - Part 1

This is a topic every developer must deal with at some point in their life.  I broke this article down into several parts.  The first part is about procedural programming, the second part is about object oriented programming, and the last part is the summary.


I did a search earlier on the pros and cons of procedural programming.  I could only get a few results.  The few results I did get were contradicting themselves.  One of the pros stated that procedural programming resulted in portable source code.  One of the cons stated a change in the application means you'll have to rewrite much of the code.  Those two contradict each other.  I'm sure there are instances when you can copy/paste and everything will work out fine.  I can assure you, that 90% of the time you'll be doing a rewrite of the great portable source code.

Another pro to procedural programming that I found stated that it's easier to maintain as you can test a procedure in isolation.  While this sounds great in theory, this is also a contradiction.  Most procedural programs require a higher usage of public variables.  So when creating your tests, you'll have to account for every variable that the procedure uses.  I hope you're religious as you'll be praying that you don't have to test this 500 line behemoth procedure.  Maybe if the procedure was divided into many smaller procedures it would be better, but I wouldn't hold your breath.

Another pro for procedural programming I found stated that your code is more flexible as you can change a specific procedure that gets implemented across the program.  I'm pretty sure they meant a procedure that is not overloaded and that they don't touch the input/output of the procedure.  Otherwise, this pro is surely a con.

Let me explain my list of pros and cons for procedural programming.

Pros

• Easier to follow along as you can step through everything.  Objects are rarely abstracted so each object you come across should make sense immediately.
• As long as the input/output in your procedures don't change you can modify it fairly easily.  Testing may make this a con as you will need to ensure that this procedure relies on the absolute minimum requirements.
• You can quickly create code and use existing procedures without requiring much thought.

Cons

• Harder to maintain (if a team is making the application) as a change (or no change) in a global variable will trickle down through all procedures that use it.
• An input/output change will more often than not require a rewrite of several procedures that lead up to and follow the procedure being changed.
• An incorrectly handled exception can be devastating as any follow up procedures may be using incorrect or no data that it requires.  (This is the same for OOP, but in some instances OOP won't cause as much devastation - Covered more in part 3.)
• A lack of some structure can create frustration because of a lack of understanding what the procedure is supposed to do.  (AddOrder(order) and SubmitOrder(order) has similar meanings.  One may mean to add an order to a cart while the other is to submit the order for execution.)

Procedural programming is great for really small teams (2 or less) that are creating really small applications.  The more team members and the larger the product will make the cons I mentioned earlier stick out farther and farther.  You can easily add functionality with procedural programming, but modifying functionality can either be easy or near impossible.  There's not much of an in between.

A Dispose Gone Bad

I'm going through some VB.NET source code and I keep seeing a common bad occurrence.  Below is a slightly modified example of the code I keep seeing.

Code Snippet

119.  
120. Dim SqlDataAdapter As New SqlClient.SqlDataAdapter
121. Dim sqlCommand As New SqlClient.SqlCommand
122. Dim dt_dataadapter As New DataSet
123.  
124. 'Set Parameter   
125. With sqlCommand
126.     .Connection = dataConnection
127.     .CommandType = CommandType.StoredProcedure
128.     .CommandText = "blah blah"
129.     .Parameters.Add("@ID", SqlDbType.Int, 8, "ID").Value = 0
130. End With
131. SqlDataAdapter.SelectCommand = sqlCommand
132. SqlDataAdapter.Fill(dt_dataadapter)
133.  
134. If dt_dataadapter Is Nothing Then
135.     dt_dataadapter.Dispose()
136.     SqlDataAdapter.Dispose()
137.     sqlCommand.Dispose()
138.     MessageBox.Show("Failed retrieving 'blah blah'.")
139.     Exit Sub
140. End If
141. If dt_dataadapter.Tables.Count = 0 Then
142.     dt_dataadapter.Dispose()
143.     SqlDataAdapter.Dispose()
144.     sqlCommand.Dispose()
145.     MessageBox.Show("Failed retrieving 'blah blah'.")
146.     Exit Sub
147. End If
148. If dt_dataadapter.Tables(0).Rows.Count = 0 Then
149.     dt_dataadapter.Dispose()
150.     SqlDataAdapter.Dispose()
151.     sqlCommand.Dispose()
152.     MessageBox.Show("Failed retrieving 'blah blah'.")
153.     Exit Sub
154. End If

This same format is being used in multiple locations.  There's probably a lot your seeing wrong with this right now, but if not then that's why you should read the rest of this article.  Let me go through this step by step. 

The developer is using objects that use the interface IDispose.  The second thing you'll notice is there is not one try-catch in this entire section.  If the connection mysteriously disappears the program will terminate immediately.  The end user will have no idea what's going on.  Crash!

Now let's say it gets past that.  Maybe he/she finally put a try-catch around the Fill() function.  The dataset has an exception, but the catch just says a message and it continues on.  If the dt_dataadapter is nothing it then goes and disposes of the dt_dataadapter.  You can't dispose nothing.  So now this results in the application crashing.

Let's choose one more scenario.  Let's say this function is called and is surrounded in a Try-Catch.  Now the application doesn't crash, however the data adapter and the command is never released from memory.  Now you have a memory crisis on your hands.  If this happens enough then the application will crash.

The appropriate and best way to avoid everything that has happened above is by using the Using statement.  The example below is about 1,000 times better, easier to read, and this won't cause any memory leakage.

Code Snippet

158.  
159. Using Command As New SqlClient.SqlCommand("blah, blah", dataConnection)
160.     Command.Parameters.AddWithValue("@ID", 0)
161.  
162.     Using Adapter As New SqlClient.SqlDataAdapter(Command)
163.         Using Data As New DataSet
164.             Try
165.                 Adapter.Fill(Data)
166.             Catch ex As Exception
167.                 MessageBox.Show("Failed retrieving 'blah blah'.")
168.                 Exit Sub
169.             End Try
170.  
171.             If Not Data Is Nothing AndAlso Data.Tables.Count > 0 AndAlso Data.Tables(0).Rows.Count > 0 Then
172.                 ' Do something with the data here.
173.             Else
174.                 MessageBox.Show("Failed retrieving 'blah blah'.")
175.                 Exit Sub
176.             End If
177.         End Using
178.     End Using
179. End Using

This works because whenever this method is completed it will automatically call the dispose for each object that uses the Using statement.

If you see anything wrong, or have any questions, please leave a message.

A Misconception Of Object Oriented Programming

I was reading another object oriented programming blog earlier and read in a comment that they didn't understand why anyone in their right mind would use OOP and said that it lacks real world objects.  He or she then began to say why with an example.  He or she said that you can have a person class, a worker class which inherits the person class, and then a student class that also inherits the person class.  He or she then began to state that now you cannot have a student who is also a worker.  They said it's impossible. 

Why is this impossible?  This is the exact reason to use object oriented programming.  The person class should have a PersonID which is a unique value.  Why can't a worker class and a student class point to the same person?  I think their problem was how they were perceiving the data.  Obviously, the worker can't be of the same type as the student.  When you grab data (from a database in my example) you would most likely would be grabbing a specific type.  You would either have tables that holds workers and students or you would have a Person sub table that would be able to hold additional or multiple types.  Below is an image of the second description in how it would look.

The PersonType table simply points a person to a type.  The type then points to a worker or a student.  It could someday point to hundreds of other types.  If you need to get all workers data then you can do so by ensuring the TypeID in the PersonType table has the description of "Worker" or whatever you want to use.  You would then create the instance of the worker class that inherits from the PersonID.  The beauty of this being object oriented is now if you make a change to the person in the worker table, it will automatically be updated to the person in the student table.

Again, I believe they were having trouble imagining this in their head.  Yes, you can't have two objects that are of different types as one type.  You're not ever supposed to.  A Ferrari is not an F-150.  They can't be and aren't supposed to be.  A worker is not a student.  A student is not a worker.  A person who works CAN be a person who is a student and a person who is a student CAN be a person who is a worker.  I don't give grades to workers and I don't think any college would plan on paying any student a salary.

Simplifying An Application with Object Oriented Programming

There are still a high number of professional developers that do not use object oriented programming.  They claim that there method procedural programming is sufficient and has no side effects and is easier to use.  Some may even believe that procedural programming is object oriented programming.   The difference between the two is very subtle, but the results are not.

I altered an application that used procedural programming and changed it to an object oriented program.  The application would load orders from a file and then compare those orders from a database.  If the order was found in one and not the other then it would show that order.  The problem with this is the orders from the file have to be modified a little bit to ensure that the data is able to correctly match up with the databases data.  The file gets loaded into a datatable object just like the orders from the database.  However, the fields aren't the exact same.  The name of the commodity on one doesn't match the name of the commodity on the other.  An option order comes from the file with a field "OPTION" and from the database it's a 1.  Also, the data from the database comes in a different column and so on. 

So the goal is to match them off, but to make it match it off in the easiest way possible.  With the procedural programming it would work, however there would be column movements just before they get matched off.  Some of these were coming as the field number and others were movements with column names.  It really ended up becoming a huge hassle and a mess to make any corrections.  A movement of one column made all of the other columns move and so it was kind of like a Voodoo programmer stepped in and made it work.

I'm not that smart of a guy to keep track of all of these moving pieces.  So in comes object oriented programming.  The first thing I did was to create an interface called IPrelimOrder.  This interface was nothing, but a collection of properties. 

Code Snippet

8. Public Interface IPrelimOrder
9.     Inherits IComparable(Of IPrelimOrder)
10.  
11.     <DisplayName("Trade Date")>
12.     ReadOnly Property TradeDate As String
13.     <DisplayName("Commodity")>
14.     ReadOnly Property Commodity As String
15.     <Browsable(False)>
16.     ReadOnly Property CommodityConversion As String
17.     ReadOnly Property Contract As String
18.     Property Price As String
19.     ReadOnly Property Buys As Integer
20.     ReadOnly Property Sells As Integer
21.     <DisplayName("Option Type")>
22.     ReadOnly Property OptionType As String
23.     Property Strike As Double
24.     <DisplayName("Account")>
25.     ReadOnly Property AccountNumber As String
26.     <DisplayName("Source")>
27.     ReadOnly Property DataSource As String
28.     <DisplayName("Ticket #")>
29.     ReadOnly Property TicketNumber As String
30.     Property Checked As Boolean
31.     <Browsable(False)>
32.     Property DataRow As DataRow
33.     <Browsable(False)>
34.     ReadOnly Property OMNI As String
35.     <Browsable(False)>
36.     ReadOnly Property FirmID As String
37. End Interface

Then I created a class called DatabaseOrder and FileOrder that implemented my newly created IPrelimOrder.  No more column moves.  The other benefit to doing it this way is now I can store all of this data into a list(Of IPrelimOrder).  If I need to know whether this order came from the file or from the database I simply check the type.  I no longer have to guess and move things around and pray it doesn't create another bug.  When I get the contract name from a file, I can do a quick query to get the correct name.  I don't have to worry about getting the correct name and then moving the column to a different spot to only find out it got the name of the wrong column which threw an exception.

Later on I do internal queries on this same list(Of IPrelimOrder) where I only want to lookup orders from the file.  I can do the following.

Code Snippet

677. Orders.OfType("FileOrder")

You can separate the two using procedural programming, but it's so much simpler this way. 

If you have any questions or problems or see something wrong, please leave a message.