Unit Testing is Not a “Figure It Out Later”

If you buy into the excuse that “We don’t have enough resources or time to start Unit Testing now”, then you buy into the hack it now, fix it later approach and I don’t respect that.  Unit Testing should be something you learn NOW especially when you have a fresh opportunity do so such as a on a new web project that’s being coded from scratch.  There are not many projects which you can start fresh on and include Unit Testing like this, and when you have that chance, do not let it pass away.  Businesses find it easy to keep adding features to produce scope creep but they can’t fit in extra time for adequate testing which I feel is just appalling.

If someone tells you to wait and do it later on the “next project”, it’s really not their decision.  Unit testing is for programmers and is done while you code.  It’s a decision done by the programmer because he/she cares about better code and less bugs for the good of the team, the business, and its users. 

Unit testing is not a big of a deal.  All you are doing is creating very small little tests which only take a couple minutes to code up per method you are testing.  If I take and create 5 controller methods today for my MVC Web project for example then I expect to take 10 minutes out of my day to create 5 small code snippets for testing those methods.  To me, that is not a big deal.  Even if I took 20-30 minutes, it’s not a big deal considering all the time I spend on bullshit with other aspects (email, etc.) in the office.  I know that in the end I’ll be able to run these tests and have them tell me where my code breaks when introducing new code in the future. 

Now why would I not want this added comfort and savings in the future when I’ll have less debugging because my tests tell me if code fails instead of me manually debugging code that I have no clue why it’s failing?  It seems to me Unit Testing is something that’s obviously an item that should be required of every programmer on any team.  When we have tests we can run, we can see where code breaks immediately instead of spending 20-30 minutes in some cases doing the contrary…moving through the debugger finding bug after bug and fixing bug after bug and never knowing how many MORE bugs there are to fix.  That’s going backwards.  Leaving testing to last is ignorance.  So I promised myself this time through I’m adding unit tests to my new MVC project.  My mentality is not one which can allow things to just go array and I can’t stand when process is backwards.

Testing last or not testing at all to me asks the question why are we coding in the first place if we are doing a half assed job at it?  Not testing (QA, usability, acceptance, and unit) is simply saying we don’t give a shit about quality and the business enough to do this.  And that we enjoy or are willing to put up with constant fixing of code.  I know that personally I did not go into IT with the expectation to keep fixing bugs, I like spending my time on more important tasks for the business.

And who wants to sit all day and talk to QA about bugs that we probably could have caught via Unit Testing?  QA's job is not to catch code bugs, it’s to test whether the software has met the business requirements.  It is our job as a programmer to add that added layer of testing before it gets to QA.  And why would we not want to help ourselves by testing?  Why would we not want to save ourselves time through the development process?  It’s just a done deal to me and completely stupid not to unit test.  It’s not hard to write a few lines of code to build confidence and trap errors which would have taken us much longer and surface many more surprises when not doing so during any project and it’s just beyond my comprehension why developers or management fight this very topic. 

And remember, Unit testing is very misunderstood.  People think it takes a lot of time to invest in doing so but it’s very small in comparison to the cost and time savings reaped when it’s done concurrently in development as you go.

A couple of books I’m currently reading and highly recommend.  They are very short reads so you can get to the points/techniques quickly:

Today I promise that “I will never write an application again without unit tests”, and you should too. 

If you care about code quality, business process, the business you work for, and respect for yourself as a quality developer, less bugs for you and your end users, and ultimately getting shit done and going home sooner because you had less bugs today to work on, therefore I can now spend more time with the family, then you’ll promise yourself the very same thing starting today.

posted @ Saturday, June 06, 2009 1:00 AM | Feedback (11)  

Top 10 Reasons Why Employees Leave in IT

Share this post :

In no particular order of weight (but would have to say if I had to give it a weight the highest would be on #1, #2, #4, #7, #9, and #10).  Before you read this, you might want to read my philosophy on what a Good Manager / Lead would be.

1) Code & Run Shop

• No industry best practices / development standards in place
• No time built into schedule for testing, SOLID practices, or time to even think SOLID
• expectation of everything big or small to be coded in 1-2 days or other totally unreasonable timeframes and no attention to refactoring bad code (technical debt) leads to chaos
  • Timelines are based on no estimates or are pushed by managers who have no insight or care to the process at hand.  Estimates are pushed by managers at the blink of an eye and literally pulled out of thin air without any type measure whatsoever
• No prioritization on items therefore constant interruptions in projects are the norm leaving projects unfinished due to a shift to “yet another project or task unexpectedly”
• Excuse is “business needs it now” instead of lets try to get this thing out in a reasonable timeframe with testing in mind, and attention to quality code
  • Working till all hours of the morning fixing hacks or entertaining scope creep due to features added the night before!  sad but all too true in IT which ultimately will lead to the good employees jumping ship

2) Absolutely NO structure

this is typical for mom & pop shops or those shops who have people who have never worked anywhere else BUT the company they work for.  They’ve worked for the company for 10-20 years and do not know what “reality” is outside their environment and ways of doing things overall

• This causes a code & run shop but I’m talking about absolutely NO structure here (see bullet 2).  Code & run can come from lousy structure but no structure is even worse
• While too much structure is not good, no structure is complete stupidity and ultimately complete Chaos
  • No priorities on queued tasks
  • No reason why we should even do task A, B, C but just do it cause the boss says so
  • No source control
  • No true Development, QA, Staging Environment (one or all)
  • No Bug system with prioritized task lists
  • Bug system has tasks or manager has them in his head but thrown out to the team at random thus interrupting their current tasks at hand without regard to what’s more important to the business.  Disrupting someone’s current project and throwing in an unnecessary project prevents progress when there is no structure to these tasks being handed out.  Tasks are handed out for no reason other than “I think it should be done”, not “Do we really need to do this or does this have more business impact or am disrupting the flow”
  • No testing (Unit testing, QA, Usability) is added to project timelines and testing is only done by developers at best which is NOT testing

3) Lack of regular communication

• Everything is kept behind Closed Doors or at an “As need to know basis”
• Too many meetings that do affect you but you are not included
• Mysterious meetings happen and they are mysterious because the people who hold them hold them off site every time or behind closed doors.  This creates a lot of suspision in many cases and therefore it’s a closed environment
• Boss doesn’t communicate things that affect the team or you as an individual and makes all decisions without your knowledge only you finding about it later through another source
• Not able to get solid answers to your questions (about the business, procedures, decisions that affect the team, you name it)
• Emails are not responded to (the important ones).  When you attempt to ask them in person, the question is dodged or you receive an answer that completely does not provide you any information at all
• Communication mostly done through email.  This is not good communication and that’s common sense people.  Talk face to face when at all possible, stop hiding behind emails.  That’s mom & pop mentality.

4) Micro Managers

• Managers that constantly have to babysit rather than trust their employees to do their job.  Constantly checking in daily and worse, when checking in just checking in for status checks.  Give your employees space or they will leave

5) No recognition of the work you’ve done and effort you’ve put in

• Managers do not take the time to show their appreciation by a simple “good job” once in a while
• Colleagues or managers take YOUR idea as their own.  Lack of credit to the people who gave you the idea in the first place
• Managers who only harp on the fact that you can’t get things done fast enough, even if you are doing the “norm or above”

6) Reviews that are mostly all negative most of the time

• It’s ok to point out some weaknesses or things that you think your employee can do better, but the entire review should be mostly uplifting if you value that employee.  Don’t make it a session for “you suck” but rather motivate them and tell them what they did do right.  At the end, talk 10 minutes about what you want them to improve and leave it at that.  It’s pointless for your employee to leave unhappy from a review if you value that employee.  You want them to leave motivated if you are keeping them long term.  Consistent “unfair and demeaning” reviews that make the employee feel that they are never good enough for you drives employee motivation down and eventually away from the company
• In most cases, managers completely miss the work you've actually done.  Lamely enough they ask YOU to evaluate yourself.  This is one of the lamest procedures I've seen and it happens a lot at companies.  They ask you to evaluate yourself while it's THEIR job to remember and jot down what YOU did and recognize you for these projects.  Instead they focus on what you did not do and where you fall short.  This is not a smart review my friend if you're the manager.  It completely disregards your employees contributions and efforts.

7) Politics

• This plays into many areas but typically it’s caused by bad apples.  Those colleagues or managers who play favorites, who always are easily persuaded by other bad apples (cocky arrogant loud mouths), and those who make decisions not based on the situation or how an employee really has done but makes decisions to further themselves or based on peer pressure from others rather than decisions that benefit the employees or company as a whole
• Managers who give out or try to promote others up the ladder because they are “friends” rather than based on their “performance”.  Managers who fail to promote the very people who deserve it rather than who is popular or who they like rather than who really deserves it and has a great attitude and has worked hard for the company

8) Bad co-workers who do not get stomped out (let go) and hurt the culture

• The arrogant bastard 
  • This guy always has to make a cutting or cocky remark and is typically very very LOUD in addition to his cutting remarks.  Always has to act macho and talk in a passive aggressive tone to almost everyone naively thinking that it makes them look like a person of importance.  It’s a shield for them as they believe if they initiate a conversation aggressively, that the person will actually listen to them and think they are important.  Instead, the effect is disrespect to the to others, and disrupting the culture and environment around them
    
• The Kiss Ass
  • This person could also be an arrogant bastard.  Often times they play both.  They kiss up to people and go to lunch with those people who they are trying to kiss ass to.  They do it on purpose to try to change situations which don’t affect them and purposely set events and meetings to go against someone else.  They often are paranoid and kiss ass because they are not good at the job that they do.  Reality is, they lack smarts
  • This person could be dumb or could be smart.  But they have no confidence which is equally as bad as being dumb
• The Nosey Loser
  • This guy always has to be the life of the party in order to find out what’s going on in the office.  Constantly interrupting conversations so that they can butt in and shed a light or two on something that completely has nothing to do with him/her
  • This guy constantly asks “what are you guys talking about”
  • This guy seems to walk into every meeting you have with your boss just to nose in and figure out what you’re meeting about.  Typically this person is not in your department  at all in fact and has no business butting in constantly.  Instead they should stay in their office and get some work done and relax
    
• The Lazy Snail
  • This dude always sluffs off.  Does half the work and goes home.  Not good for the team
• The Idiot manager
  • This guy doesn’t know technology.  Constantly promoting datasets, he thinks he’s a genius.  Throwing out management terms even he doesn’t yet understand.  Expecting the team to work in IE 6.0 and wonders “what’s this FireFox thing you’re using?”
• The Know-it-All
  • They’ve done it, seen it, eaten it, created it and in fact much better or more than you.  This person hurts a team because they are not contributing, they are bragging and wasting your time

9) No work-life balance

• Those who preach it but truly are bluffing are burning their employees out.  Eventually they leave.  We are humans; build that into the system and let us relax while we do our job, outside of just vacation once in a while
• Yes, "business has to get done" (really? ya think boss?? Did not know this), but lets be real people.  If we're working hard already, stop using business as an excuse to drive your employees to death

10) No concept of “Team”

• Employees are expected not to question anything, just do as told.  This is NOT “Team”.  Constructive criticism or going against the grain in a constructive fashion (not rude or out of control) is viewed as a problem rather than a positive.  Teams work best when they collaborate and are allowed to question what the proposed process or standard is, not just following and doing what is told 100% of the time.  If the process suggested or currently ongoing sucks, question it and expect your team to question it!
• Manager not listening to and taking advantage of his employees and what they have to offer from their own experiences current or past
• Consultants driving the business rather than the internal IT group.  Consultants driving bad code or bad practices in environments.  Not saying all consultants are bad but often times they do drive a lot of bullshit and unnecessary costs (refactoring, conflicts, self-interest) which hurts the team.
• Manager is so stubborn and ignorant that “everything I say is right” and is constantly fighting to make himself “right” even if he is not
• Employee has a breadth of experience in many environments but you continually are stubborn as a manager and make all the decisions rather than tap into and ask that Lead or employee a better way or process that could benefit the team as they’ve done it before
• Employee comes up with an idea and manager disregards it because “no I’ve always done it my way” even if it’s a 1999 way of doing things
• Employee comes up with a better idea than yours and you being the manager continually disregard those ideas that are better it because you are weak.  Managers should be utilizing the people they hire including their ideas if they have a better process or idea/reason in mind.  If you cannot, you suck as a manager.  Your way is not always right, and most often 50% time wrong even if you are a very smart person

And all of these CAN be corrected or prevented if managers did their job to ensure this shit doesn’t happen.

Share this post :

posted @ Sunday, May 31, 2009 10:28 PM | Feedback (27)  

Why Should I go to a Code Camp?

First off, what’s a Code Camp?  Well, it’s merely an extended user group meeting of sorts (in my opinion) that is all day with great presenters presenting on a variety of topics including great food & door prizes.  That in sum is a “Code Camp”.  The difference is, they are not just presentations but the presenters will also code and show you examples live as they explain a topic (can’t get any better than that!).  And a lot of times these presenters are coming from all over the U.S. in many cases to your local camp.

Why should you attend one?  To learn code?  Sure, but more importantly it’s much more than just code.  Today I attended a Code Camp for the first time (specifically this one was in Chicago hosted by LCNUG).

Here are some reasons why YOU should get off your ass :) and take time to attend one:

1) To network with people and have a good time

2) Really motivates you to get into code in those times you’re sort of burned out.  Gets you excited about code again

3) Allows you to get a refresh on latest good practices & code patterns that are being used

4) From talking with people or listening to presentations, you’re able to formulate a nice list of key “terms” that you can bring back with you and look up and research / practice to better yourself as a developer

5) Free food & prizes! (great books, software, etc.)

• Today I won a copy of Vista Ultimate (yea yea, Vista sucks, but I like it so screw all of ya :P.  XP is old hat in my book and windows 7 will allow us to get rid of that XP addiction).  Hey, it’s a free OS so I can’t complain.

And please don’t think you’re the only one who doesn’t know certain terminology, code techniques, or the latest code.  All of these “presenters” are in the same boat as you but some are just a bit more advanced or versed lets say which is why they have the confidence to get up and preach.  Yes the presenters are very sharp and are good at a variety of things BUT they also learn from each other on the sidelines all the time as well and even from sitting into other presentations themselves.  Just because you’re not presenting doesn’t mean you’re dumb, not as good as a coder, etc.  It just means you’re interested in collaborating and learning what others are doing.  Just because you’re already very smart and know lets say design patterns well is no excuse not to go to a code camp.  There are MANY smart developers there and it’s just a really great place to collaborate and learn together and ping ideas or trends off each other. 

For instance I was talking with a presenter about the Spark View Engine vs. NHaml.  Learned that NHaml’s framework was or is being refactored and there are some rendering issues with NHaml such as it adding unwanted line breaks in your mark up whereas Spark doesn’t pose this problem.  I have not attempted to use the Spark view engine for ASP.NET MVC yet, so this is good to know and these are the types of things you learn quickly while attending and talking to people at a code camp.

Here is a great  a list of terms I wrote down from various discussions or presentations throughout the day, that I thought was a great list for researching more on.  Some are basic concepts, some are not and some I really need to just brush up on again after having not used them in a while.  Many of these terms I already sort of know but some of them now I’m looking up again in a new light for use with a new technique or purpose. (forgive me if I spelled some of these wrong, I did not look up and verify all of these, just scribbled them down today).

• getHashcode
• immutable
• best way to handle null refs in ASP.NET MVC views
• Mutators
• Serialize / Deserialize
• Factory Method
• Visitor Pattern
• Repository Pattern
• Imperative programming
• Immutable strings
• Expression builder using mutable symantecs
• Expression trees
• Expression tree iterators
• line of business vs. framework code
• Static analysis in code contracts
• Debug symbols
• Object invariance
• Integration testing vs. Unit Testing
• The stack
• Lambda expressions
• Static Classes
• Concrete Classes
• NDepend
• Flipping bits for security (user access)
• Observable collection
• Observation pattern
• Object initializers in .NET 3.5
• Mutex
• Unit testing multi-threaded code (very hard to do)
• Enumerable
• Whitebox testing vs. Blackbox testing
• Reflection emit
• Dynamic Proxies
• Method invocation
• Mocks vs. Stubs
• Partial Mock vs. Dynamic Mock, vs. Strict Mocks
• Mocking is really an isolation framework

And Some Good Resources I wrote down:

• Book (which I’ve already pre-ordered last month already): Art of Unit Testing by Manning
• Jeremy Miller’s blog (stuff on Unit Testing)
• MetaLinq on codeplex good example of using expressions
• Martin Fowler’s post on Mocks vs. Stubs
• Uncle Bob’s Blog – Test Driven Development
• John Smith’s blog about MVVM in WPF

So I hope you take a day out and try a Code Camp.  It’s not you sitting down coding, the presenters are!  You’re learning the entire time and getting up to speed on the latest.

posted @ Saturday, May 30, 2009 10:46 PM | Feedback (0)  

Shout Out to Ryan Reese – CSS Guru

I want to introduce you to who I think is one of the best resources on the net for CSS and tableless design or just CSS in general.  Ryan has been helpful in many occasions in times where I needed to figure out tricks in CSS and his website is full of very relevant articles.

Hats off to Ryan and may you realize this great resource in your daily workings with tableless design and CSS pains.

Keep up the great tips Ryan.

posted @ Thursday, May 28, 2009 9:18 PM | Feedback (0)  

CSS Image Mouseover with <li>

posted @ Thursday, May 28, 2009 8:48 PM | Feedback (0)  

CSS Tabeless Design Basics – Positioning Content with Floats instead of Tables

posted @ Thursday, May 21, 2009 12:13 AM | Feedback (4)  

Subversion Key Points Condensed

posted @ Sunday, May 17, 2009 10:46 PM | Feedback (0)  

Summary of Agile

posted @ Sunday, May 17, 2009 8:57 PM | Feedback (2)  

Intelligentsia Coffee Tour

posted @ Saturday, May 16, 2009 10:00 PM | Feedback (0)  

Foo is Gay

posted @ Sunday, May 10, 2009 3:58 PM | Feedback (5)  

How Would You Run a Business?

posted @ Sunday, May 03, 2009 12:23 AM | Feedback (1)  

jQuery Tabs Plugin with Images

posted @ Saturday, May 02, 2009 8:25 PM | Feedback (6)  

Interviewing the Interviewee

posted @ Thursday, April 30, 2009 10:29 PM | Feedback (0)  

Organize your Personal Resources – Just use a Wiki!

posted @ Sunday, April 26, 2009 10:12 PM | Feedback (2)  

Getting up and Running Quickly with ScrewTurn Wiki & SQL Server

posted @ Sunday, April 26, 2009 8:34 PM | Feedback (0)  

C# Regions are not Useful? Give me a Break

posted @ Sunday, April 19, 2009 10:05 PM | Feedback (36)  

Piggyback on Derik Whittaker’s Post on Refactoring Project Structure

posted @ Wednesday, April 15, 2009 11:23 PM | Feedback (0)  

Subtext Admin Password Does Not Work

posted @ Monday, April 13, 2009 1:01 AM | Feedback (0)  

jQuery Link Repository

posted @ Saturday, March 21, 2009 1:43 AM | Feedback (9)  

What Makes Code Unbearable to Work With

posted @ Thursday, March 12, 2009 9:51 PM | Feedback (5)