//TODO: Create Blog Title

In the last few years, I have interviewed a number of college students and graduates (Computer Science) and recognized an obvious deficiency in real world skills. While most have gathered details on how to work independently and discipline themselves to learn, the students lack exposure to life outside of a classroom. Those that understand stand to perform better since they are familiar with expectations.

What can the other candidates do to improve their chances of landing a decent job straight out of school?

…But I Have Straight A’s

Straight A’s will not make you a CEO, only a great entry level employee. Straight A’s means you are great at doing assigned work. Leading a company requires social skills, vision, and creating work when there is nothing tangible there.

– Ryan Healy in 8 On-The-Job Rules You Unfortunately Can’t Learn in College

Note: I am not making excuses if to not finish the curriculum. Put some effort in and you will be out soon enough. After all… I made it.

Traditionally in academics, we provide you problems that teach core concepts: object-oriented programming, data structures, proper database design, etc. Beyond that we need to foster the ability to perform independent thought and collaborate. You should receive an overview of software design patterns, when and where it is OK to sacrifice quality for the sake of performance, or to how to make accommodations to meet a deliverable.

The real world is much more open-ended. You are responsible for the decisions you make. Did you make a design decision that supports reusability? Does the design pattern hinder the ability of the application to extend beyond its initial scope?

Defining your own design, also requires you to sell that design. If no one else is biting, most likely it’s a bad decision or was explained poorly. Not everyone will agree and will find points of design failure. Expect that. Your ability to mitigate failures those will improve with experience.

Requirements?… Check

Requirements always change from start to finish of a project. Be prepared to be told your release date has been moved up a week or you are responsible for an entirely new set of features. How does this impact your current work to date? Do you need to modify your design without a complete rewrite? You may also be forced into a negotiation for what features are important enough to hit deadlines and which can be left out.

Twenty-One Year Old Looking for Solution Architect Position

Leading teams of one or two does not qualify you lead developer. No developer position in college prepares you for the pressure of the role of solution architect, responsible for multiple implementations and ensuring teams have a clear understanding. You will not know how to manage until you really manage.

Instead focus on team player skills. Work on an open-source project. Build a solution that solves a problem. Leadership skills are identified when you state, “I took ownership of building the flux capacitor by proposing a design to the rest of the team, and after some discussion, built a proof of concept and focused on integrating with the solution.”

Coding by the Book

Working with teams will get you exposed to other developers’ source code. When you went through your introduction courses, everyone was taught to code using the same standards. Just like fashion, people change coding styles over time. Stop reformatting their code to follow your standard and evolve a set of standards that the team will adhere to.

Stop Wasting Time Rewriting Existing Code

Moving into my last point, it is important that you build core understanding of basic data structures and OOP. Once that foundation has been laid, in the real world, you need to focus on using external libraries, and code that has already been written. Understand how frameworks are designed, how to integrate with third party components, and when not to reinvent the wheel. While doing this, you will easily see that there are many different styles (interaction, development, standards) that other authors use. In doing so, you may create your own unique development style.

As a last point, the following are skills I was not taught in college that are important to understand post-classroom:

• Developing simple reusable libraries
• Web services
• Proper exception handling
• Debugging techniques
• Writing unit tests
• Revision control and source merging

What do you think students stand most to understand before entering the workforce?

I have used the Entity Framework for two successful project implementations. In my opinion EF lies somewhere between "awesome framework that makes application development a breeze" and "generic tool that requires too much effort to do anything besides out of the box".

Before I explain myself, I need to identify the common patterns I think are necessary in any application that needs to persist data:

EF works to simplify the development for database dependent applications by removing the redundant work involved in each project. Namely, the below highlighted tasks:

What is so bad about Entity Framework?

1. Most developers do not know to optimize database operations. EF creates a sandbox so that they may do whatever the hell they want with the data. This will drive any DBA crazy when they are asked to make optimizations.
2. With 99% confidence, I believe that most of the .NET framework code is bug-free (or has yet to become a problem for me). Knowing this, we can believe that our EF SQL queries are probably legit. But isn’t it important to test our queries themselves through unit tests? The ability to unit test our own data access methods without requiring an active database (in-memory or XML defined?) is a necessary feature.
3. Consequently, the application is fully aware of the ties to the EF and cannot be tested without. Persistence ignorance support is necessary so that developers are not forced to implement additional interfaces or provide unnecessary references.
4. Developing N-Tiered Applications with EF is difficult. Reattach objects into the data context after client modifications requires too much work.
5. Lazy loading improves performance, but excess code is needed to check if a related set is loaded. If it is not loaded, additional code is required to perform the operation. Consequently, it could make database operations unnecessarily chatty.

I am only able to list five points about what is bad about the EF, after working on it for 8 months. In that time I have managed to work around two of the five issues with ADO.NET Data Services (unit testing data access methods with a mock implementation and creating N-Tiered applications). Performance issues have cropped up that I am 100% confident would not exist if custom code had been written to manage data access.

So what is the ‘Entity Framework Balloon’?

Someone once provided this analogy to me.

If our project were a water balloon, each development task would have its own piece of space. The introduction of EF attempts to shrink the cost/time to do the redundant tasks by compressing that side of the balloon. But the other tasks have to go somewhere else, and their piece just gets bigger and requires more effort in the long run.

There always seems to be a new tool for the job. EF obviously serves its purpose, but it fails at making everything as easy as it seems.

.NET 4 with the new Entity Framework

Looking ahead, the ADO.NET Team Blog has focused on a list of concerns for the next version of EF.  They are focusing on improving:

1. Enabling settings to make development simpler such as lazy loading, eager loading, and stored procedure mapping.
2. Improving the readability of the generated SQL.
3. Persistence Ignorance support, allowing you to write POCO and later tie them to Entity Framework or another Data Provider.
4. Better N-Tier Support allowing the serialized entities to include their own change tracking properties.
5. Model-First and Code-Only development!
   

    

   Entity Framework Reading List:

   Anti-Patterns to Avoid in N-Tier Applications
   The Entity Framework in Layered Architectures
   What’s New and Cool in Entity Framework 4.0

I just could not resist reposting Scott Hanselman’s most recent post: 2009 Ultimate Developer and Power Users Tool List for Windows.

I am currently waiting for parts to come to rebuild my home machine and install Windows 7 on. I cannot wait to review every item in this list to see if they increase my productivity!

Important lesson for those who prefer using GUIDs as record identifiers.

The MS SQL data type, uniqueidentifier, does not have a counterpart in Oracle. In the past it was easy to make the column CHAR(36), the max string length of a GUID. I was not in a situation to do this as we were dealing with the Entity Framework against Oracle. 

Entity Framework is compatible with SQL Server out of the box and translates the uniqueidentifier column to GUID type. This is not the case for Oracle. The use of a third party adapter, dotConnect for Oracle, is required. This provider requires that the storage data type for GUID be RAW(16).

What’s the problem with RAW(16)?

GUID representation

{922B0A87-7A88-DE11-BBA7-0AEA0522E79F}

RAW(16) representation

870A2B92887A11DEBBA70AEA0522E79F

As if it was not tough enough already to read and write a GUID. Now it is represented differently in Oracle!!??

The best solution that I discovered to get around this was through the use of a handy GUID Converter. I don’t know how many times I have relied on this to help me out.

1. Setters that do more than SET

All property setters should validate their input and set the value of other properties. This will remove the burden of validation from other developers.

Workaround: Property getters and setters should only save and return values. Getters and setters should not validate against null, perform regular expression checks, or typecast. Additional logic can take place in business logic classes. Setters that do more than set also cause issues during unit testing. What goes in, must come out.

2. The Golden Hammer

Whenever implementing something new, remember the last successful (or similar) experience and reuse.  There is no doubt about it. What worked for you in the past, will continue to work for you now.

Workaround: With the Golden Hammer approach, your solution is the hammer and every project you come up against is a nail. If you find yourself trying to implement an exact replica of a solution that you built in the past, chances are that you will miss some requirements or pigeonhole yourself into somewhere you do not want to be. Instead, step back, learn what the functionality of the system must be, and compare/contrast the differences between past experiences.

3. Swiss Army Class

Just as in bloated class, minimize how many separate classes your code must deal with. If you know all of the different functional areas your application needs to cover, extract them to an interface. Using interfaces will allow you to switch out the implementation types without changing your code. Just make sure that you keep your number of implementation classes low so that it is more maintainable. If necessary, make the lone class implement every interface in the project.

Workaround: Focus on keeping the implementation of your classes very specific to single units. If you feel the need to implement multiple interfaces to create a hybrid of a few simple interfaces, this is perfectly acceptable.

4. Yet Another Damn Layer

Encapsulation is one of the greatest features of object oriented programming. If you can find a way to make existing code more generic so as to make it easier for implementation efforts (and less code writing!) you should do so. Create a generic interface that will take care of defining all of the different functionality in one call.

Workaround: Encapsulation should be used to hide any of the internal mechanisms of a separate software component. Good examples of this are code that is used to perform common tasks such as logging, serialization, or instrumentation metrics.

5. Unit Testing and Stale Data

Since testing is usually a hassle to go through, try and spend as little time doing it as possible. It already takes long enough to set up the tests and the test data. Try not to worry about clearing out the test data since it is only in the development environment.

Workaround: Unit tests should take care of setting themselves up and tearing themselves down. Unit testing should and can be a full-time job position as it should account for every possible variation of data input and output that can occur. If you can not write your unit tests to clean their test data up, then they should use in-memory data providers so as not to impact any other users in the same environment.

* DISCLAIMER * Please note that my views are that of the Workaround type method and this article is meant to prove humor at what can go wrong when unsafe practices are used. Also keep in mind, I’ve probably done each and one of these plenty of times in my career.

It’s 4:00 on Friday afternoon. Do you know where you want to be?

Definitely not at work. About fifteen minutes before you decide to log off and bolt out early, a critical defect is logged with your application. Your data import isn’t working correctly and it is losing content during execution. The client, and project managers stress to you that this is a must fix issue as the testers cannot continue until your content is valid.

You grumble, sit back down, and pull up the code to inspect the issue. Ten to fifteen minutes later the fix looks relatively easy. Excited that a resolution was identified so fast, you settle in and begin the fix. Shortly after the fix is in place, you test to make sure everything continues to work as is…. then you gasp as you realize what happens next: it is the Whack-a-Mole bug.

whack-a-mole bug n 1. a defect that reappears throughout your application in multiple locations and is difficult to get rid of no how many times you attempt to get rid of it

Related Code-smells: DUPLICATE CODE, SHOTGUN SURGERY

Most often this code smell is a by-product of Shotgun Surgery. While it may seem easy to copy the same validation code used during data-in to data-out, you know it is not the right choice. Now later on, that specific code had particular issues and it must be fixed in more than one place.

A few months ago I started working on a new home project that I wanted to keep under source control. My only requirement was that it be closed-source as I wasn’t ready to share my idea with the world yet. I am cheap, and I decided to look for a free alternative first before I decided to pay someone. I stumbled upon XP-Dev.com.

What I get with XP-Dev Free:

• Subversion Hosting up to 500 MB
• Unlimited number of Projects
• Wiki Pages
• Blogs & Forums

XP-Dev.com has only suffered one outage since I’ve been with them, and the owner of the site was very vocal with what the status was for getting back online.  For any new projects that you are working on, or if you want to have something under version control, I definitely suggest using XP-Dev.com.

The other day while eating lunch the topic of newborns came up. We discussed that when parents prepared for a newborn to enter their home, they gave their best effort to ensure that the home was “baby proof”. Outlets were covered, stairway gates were in place, and cabinets locked to stop the little one from getting into trouble with anything in reach. Now they look back as their children become mobile, and say a whole new can of worms is opened. Cabinets are not locked to protect what is inside. They are locked to prevent them being turned into steps to get other items originally out of reach.

Baby proofing your home serves as a solid analogy to writing software. As much as we wish it were not true, we unintentionally write buggy software. If you are lucky, the bugs are never found once the software goes out the door. Try as much as you wish to hide the errors and gracefully recover, there is always some way to work around the system. Users are just like babies in that they just putter around in the application trying different things until they find what works. They may not be expect to find these issues, but once they find them, watch out because they’ll remember how to get back and exploit what you hoped was "safe software". The Twilight Hack for example allowed Wii users to exploit a buffer overflow just by changing the name of the character’s horse.

It is very difficult to try and prevent this seeing how you cannot really tell exactly what you are looking for. Keep in mind though that software development is a lot more forgiving than raising a child. You cannot run usability tests in your house to see how safe it is. The only solution that I have to getting around this is to draw from past experiences. Focus on thorough testing and make sure past issues are no longer a problem.

Below is a refresher on the types of software testing that most products should undergo:

• Unit Testing – validate that individual units of your code work for a given input and expected output. Never rely on external factors to write your unit tests (e.g. Database Engine having correct data and up to date)
• Integration Testing – ensure that you are clear of your expectations and what you expect when working in multiple distributed environments or systems
• Performance/Load Testing – you will want to try and avoid being surprised when you get a call on Cyber Monday telling you that your site is offline due to heavy load
• Usability Testing – before you go live, do some testing on your application to make sure that you see how well subjects can perform tasks and respond to errors
• Regression Testing – remember that feature that you added in last month’s release? Yeah well now the user cannot update their profile ever since then. Regression test to ensure that updates you make do not cause existing functionality to break.
• Security Testing – is your software capable of SQL Injection? Do you follow correct authorization rules for your users and does your data retain its integrity?

1. Long Method

Short methods specific to single units are bad. Try to limit the number of methods in each class. This will ensure that each method is as long as possible.

Workaround: In order to prevent long method from happening, I recommend limiting the length of your functions to 30 lines or less (40 including exceptions).  Focus on keeping your functions less then one screen’s length.  Try bumping up the font-size of your IDE so that a lot less code fits on the screen.

2. Out of Sync Comments

Just like you learned in college, comments are the best form of documentation. Comment blocks are better. Provide details about every line of code and include pre-conditions, post-conditions, and expected exceptions. Comments are important because they help other developers calling the code understand how it works.

Workaround: If you are going to write comments, specify the problem that your code solves, not how it solves it. Think of the last time you picked up a book at the store and read the back. Would you have wanted it to tell you what the story is about, or how the plot is laid out? If you change the implementation (bug, refactor, etc.), the comments can remain the same. Try and get away from code commenting all together by writing self-documenting code. For examples read Jeff Atwood’s Coding Without Comments.

3. Bloated Class

Enforce a limit to the number of classes allowed in the codebase. To reinforce this, place all logic into one big blob class.  With this class you are the ultimate tool that can do anything. The more classes you have, the more source files you maintain. More source files increase the compile time of your project.

Workaround: Follow the Single Responsibility Principle (SRP) to keep the implementation of your class specific to its’ purpose. Classes should only have one reason to change, and no other components of that class should be affected during that change.

4. Classes that are “involved”

The more that each class knows and relies on another class, the better your code is as a single unit. New developers will need to understand every class in your solution because one change creates a ripple effect throughout the system. Dependency hell is much nicer than it sounds.

Workaround: Develop code that is loosely coupled. Loosely coupled code is attained by making each class units that do not have knowledge of how other classes work. This creates more flexible design. Do not overkill as too much can lead to unneeded code complexity.

5. Developer Ego

The smarter a developer and the better coder that they believe they are, the better the code output. The only one capable of creating awesome code is one who looks at the world as one complex problem. Try to avoid breaking it down into simple smaller problems, otherwise any regular programmer is capable of doing your job.

Workaround: Give the developer the smack-down.

* DISCLAIMER * Please note that my views are that of the Workaround type method and this article is meant to prove humor at what can go wrong when unsafe practices are used. Also keep in mind, I’ve probably done each and one of these plenty of times in my career.

I can’t help it. I read Steve’s post too big to fail on brip blap and I immediately apply its principle to life as a developer. The focus is about breaking down “too big to fail” life events into smaller more manageable components that are less likely to wreak havoc.

How is this relevant to anything in the world of software development?

1. System Design

When designing systems, separate components by logic functionality. Systems that are responsible for continuous database queries, should not be tied to a web site that serves content, such as in Simulate a Windows Service using ASP.NET. While this idea may be good in theory and for any shared hosting environment when you can’t install or run services on the server, the potential that a deadlock or frozen thread occurs will increase. If that occurs, you can kiss all of your active user sessions goodbye.

2. Application Design

Separate application logic out so that when one component gets changed, it doesn’t force a complete rewrite. Websites and web services should not tie directly to the data layer. Design N-layer systems (read the differences between N-Tier and N-Layer applications) so that there are no direct dependencies on lower-level technologies being used.

Maintainability in separate components increases as the number of layers does. Take this in moderation though, too much loose-coupling in your layers, leads to overkill and needless complexity.

3. Class Design

When designing classes, follow the Single Responsibility Principle (SRP) of the S.O.L.I.D Class Design Principles. If your class has more than one reason to change, then it may be “too big to fail”. The below example helps:

The above breaks the SRP because any minor change required to one of the three purposes of this class causes the whole class to change:

1. The process to calculate the tax rate of the employee
2. Database Schema that matches to the Worker
3. Employee Id that is used. SSN today, numeric number tomorrow

Any single change impacts the class which is responsible for three very different purposes. While this is not “too big to fail”, the class is “too big for its own good”.