About For Humans

A lot of people think programming is alien and beyond their comprehension. While some people have more aptitude for it, it's not as difficult to understand as most people think. Also, there's a segment of developers who haven't been exposed to some better ideas or just haven't heard it explained in a way that makes sense. That's really who I'm trying to reach with these articles. Building software is hard, but not as incomprehensible as some think. And some of those new fangled ideas you may hear about, aren't so bizarre. In fact, they would most likely make your job more easier and more fun if you are a developer.

Posts so far:

1. An MVC Argument For Humans
2. Beginning IT Careers For Humans
3. Unit Testing Is For Humans
4. Agile For Humans
   

What's coming up

In a round about way, I'm introducing some object oriented principles with deeper topics on the horizon. (think IoC/DI) Even the way I'm getting to it is on purpose. Except for the IT intro article which was inspired exactly how it says; by a friend/feedback. So the goal here is to explain things in simple terms, and be fairly easy to read. Your feedback helps and is considered.

I have two ideas for the next post but I'm not going to let the cat out of the bag yet. Still haven't decided which to go with next. One of them has something to do with the corny/pun-like term "ICanHazCheezburger". Don't worry; I will use that idea at some point even if its not next. It's just to corny for me to not share.

Breaking things down to their simplest part makes it easier to comprehend. We're headed in that direction with this series, but there's still some things left to cover before we get to the real meat. So stay tuned and see what ridiculous thing I say next. Even I don't know sometimes.

-j

Agile For Humans

"Be Water my friend" - Bruce Lee 

Wow! Go ahead and watch that again; I'll wait right here.
 
So you might be asking "Why Bruce Lee", and I would answer "because he's accessible/understandable." Also, the quote is somewhat relevant to the topic, which is how to develop software. By that I mean what process you can use to guide a project to completion. Sure you could go all cowboy and make things up as you go, but that doesn't generally work well. I know; I've done it. It is important to have some sort of process to drive things along and check your progress. That's really important if you are working on a schedule.
 
In this "For Humans" series, I'm trying to gently introduce software development in non or less technical terms. This is a bit tougher topic, but I will do my best.
 
There are lots of ways to do lots of things, or as they say where I grew up "there's more than one way to skin a cat." Never did understand why you'd want to skin a cat. You can't sell the pelt, and it might be illegal. Thankfully software development is definitely not illegal. Though some people say managing developers is like herding cats, skinning developers is DEFINITELY illegal. And really creepy. One traditional approach to managing software development is called Waterfall. It is strict although you can implement it in lots of variations; and the basic idea is do all the design up front and then don't veer off course.
 
Waterfall takes a lot of ideas from engineering disciplines, but software development really doesn't fit well into that model. Things change, flaws are discovered, and assumptions turn out to be wrong. To address this, a set of principles has been identified and named "Agile." No process is perfect, but Agile is rather good at adaptation, and can also be implemented however makes sense for your business or project. This is the "be like water" moment.. please pause and let the enlightenment flow from my text to your brain. Software development requires adaptation, and Agile (or XP or Scrum) is a process for managing changes in development.
 
It's a little like learning English. There are rules, but there are also exceptions. "'I' before 'E' except after 'C' and when sound like 'A' as in neighbor and weigh ..or in seize, or weird, or.." It comes down to knowing the principles and practising. In truth, I don't practise all the rules all the time. I'm not an elitist, but a pragmatist. What happens in practising is you naturally get better (obviously) and you develop better intuition about how to apply your practices.
 
Agile core principles can be found here, and core values/manifesto found here. I'll leave it to you to read those, because what's more interesting are the practices.
 
Test Driven Development (link)
This is where I do get more serious, and have already blogged on it some here(http://computeristsolutions.com/blog/post/Unit-Testing-is-for-humans.aspx). There are reasons why I'm passionate about this. For one, it really works. By writing tests first, you are really setting expectations of how your code should behave. After that, there's a natural evolution of your code into something that works, has fewer bugs, and becomes a good design. Please go back and read my earlier article for more info.
 
Behavior Driven Development (link)
From test driven development, this was a natural evolution. It's focusing on the expectation part of writing tests first; only it strives to express the intent more clearly using conventions. I'm not really sharp on the distinctions, so I recommend you read more on it yourself. Jean-Paul Boodhoo blogs often about it, and is a good resource.
 
Continuous Integration (link)
Here's another activity that will really help move your development along. Even if you are the only developer, setting up an automated build of your code will help you catch problems sooner. Think of it like driving. You wouldn't want to drive down the road with your eyes closed and only open your eyes every so often to get a peek of what is going. You want your eyes open all the time so you know what's going on around you, which is what continuous integration does for you. Kent Beck's XP books talk about getting early feedback and this is part of how you achieve that.
 
Pair Programming (link)
OK, so here is where I can't pretend to be an expert or anything like it. I don't do pair programming. I'm not saying I wouldn't or you shouldn't; just that I am not in the situation of being able to. Many of those that have swear by it. Even Ayende (everyone should read his blog) pairs up. I've certainly seen the benefit of code review. So I guess I see how this would basically be continuous code review. I do recommend considering it, especially if you are just getting into coding and can pair with someone you can learn from.
 
Agile Planning (link)
This can actually be fun. You divide up your project into small, reasonable tasks. You can use these tasks for estimates. Pick some to get done each week. Let the devs pick which tasks to do. Many agile articles suggest actually have real memo cards with each task on a board or basket to choose from. It certainly helps avoid overlap between developers. You can use the task card to plan and estimate the project to. Just estimate each task, and get help to arrange them in order of which must be done first with the remaining filled in. Simply put, breaking things down to their smallest logical part makes planning, estimating, assigning, and adjusting all easier. It's almost zen-like how it will fall together.
 
Short Meetings
This is more of a Scrum attribute than specifically an Agile attribute, but it's one I find highly useful. Keep the meetings short. Try meeting everyday for 10-15 minutes just to share status. Stand up the whole time to discourage long conversation. If something needs discussed longer, schedule a meeting or casually meet outside of the short meeting; and include the least number of people needed. Less time meeting is more time producing.
 
Conclusion
Hopefully this introduction to Agile wasn't too boring. It's tough to cover this in short and simple terms. My usual stories would take up too much extra space, and I couldn't write an in-depth article on Agile in my few spare minutes over a few nights. To learn more, read online articles and pick up Ken Beck's XP book. I recommend learning Agile if you are just starting in development, or already have but don't yet know it. You should also learn about Waterfall so you understand traditional software life cycles.
 
Those in the know, will probably notice that I mixed information about Agile, Extreme Programming, and Scrum. It's all related, and I don't have the time or space to cover it all in detail. I hope this suffices as a reasonable introduction. If I could beat one thing into your head with a really big, shiny hammer which has a red, non-slip handle, it would be that you should follow some process. I've been down the cowboy coder path, and the waterfall path. I recommend using Agile/XP/Scrum practises in most cases.
 
Additional resources:
A good read in this area is Kent Beck's Extreme Programming Explained 2. Yes it's geared to a technical audience, but I think its readable for everyone.
A little Scrum intro video: http://www.youtube.com/watch?v=Q5k7a9YEoUI&feature=related
Extreme Programming: http://en.wikipedia.org/wiki/Extreme_Programming
XP Practises http://ootips.org/xp.html
Kent Beck on XP http://www.extremeprogramming.org/
Ron Jeffries on XP http://www.xprogramming.com/xpmag/whatisxp.htm

-j

Some Quick Recommendations

We are an awesome software consulting company and I am the perfect developer who never makes mistakes, so everyone should do what I say. Use the tools I recommend or you will burn in a lake of fire after being beaten repeatedly by 1,000 angry, flaming ninjas. And a really tough, pink bunnies. With big teeth. Holy Hand Grenade!!! 

 

Authentication Versus Authorization

Authentication is the verification of who you are.
Authorization (aka permissions) is the definition of what you can do.
 
Itis a subtle difference with a giant distinction and impact. I've seen alot of time and effort put into verifying who a user is, and that is agood thing. Too often, defining and checking what the user can do isoverlooked or not thought out very well. One of the teams for a projectI'm working on is currently collecting feedback on a uniformauthorization proposal. A good amount of thought was put into how to doit and provide a good user experience. The first thing I noticed aboutthe proposal was something that wasn't in it.
 
My childhood wasfull of danger, adventure, and romance. Young Indiana Jones storieswere based on my life. OK, not really. But my friends and I did buildforts in the woods near our homes. One of them even had a secretentrance. Sure, anyone could have forced their way in and dealt withthe poison ivy consequences later, but the entrance was definitely thebest way to enter. The one thing about it was once you were in, youcould do anything you wanted in there. Tear it apart, leave kindmessages, stuff like that. Once you found the door (authenticated), youhad the ability (authorization) to do whatever you wanted. That was notgood security, but we were just kids.
 
In many applications, youneed to restrict what a user can do with the application. Letting theuser do anything they want once they log in is not good security. Thisincludes hiding a url from a menu, and hoping they don't guess itthemselves. The application needs to check if they are allowed tobrowse to "/admin".
 
What was missing from the proposal Imentioned above is definition of how authorization is checked. In thiscase, it's outside the scope of that team. But it reminded me how oftenthat is overlooked. You need to check if the user is allowed to deletethis record, or send that invoice, etc. Another question is "where doyou check?" It depends on the constraints of the project.

A goodrule of thumb is "trust but verify". This has led me to the opinion ofchecking authority twice in a lot of cases, and auditing every action.Honestly, I don't double check every time. There are a lot of caseswhere it doesn't apply. For single user apps, that single user canperform any action the app provides (unless there is some core adminfeature set). Perhaps your app isn't multi-tiered, so dual tierchecks aren't necessary. If there's only one or two layers, then youdon't need to check authority twice.

Another thing that isworthwhile is auditing. That is to record who attempted to perform whataction and whether or not it was allowed. This gives you a securitytrail to identify security related bugs or threats. It's related tologging, and is a natural extension to your logging facility which youshould be using anyway

Perhaps I should lay out how and when toapply the dual check rule, but that's not really the point of thispost. The point is this: Don't forget that authentication is not thesame as authorization and you should carefully consider both.Otherwise, you could end up with a wrecked fort with nasty littlemessages written in red paint on the rocks from taunting foes.
/just sayin'
//if I *ever* find out who that was...

-j
 
linkage: http://www.duke.edu/~rob/kerberos/authvauth.html

Leisure Reading For Enhanced Performance

I read a fair amount even if not as much as I'd like nor all of the books I'd like to read. A lot of what I read are blogs and online articles related to technology. I currently have 5 books on my reading list. All of them are technical books in PDF form. While its very important for a computerist to keep up to speed with technology, it's also important to keep the creative juices flowing in the brain.

In January, I picked up a kids book and read it. I read a majority of it one weekend and didn't do any work or computer reading that weekend. The following week, I felt a little more refreshed. Perhaps it was getting a little extra sleep or taking a real break from computerist material, but I'm sure reading helps.

I'm a big believer in reading being good for you. I mean exercise is good for your body, right? Then why not exercise your brain. Something about reading stimulates your brain, and reading different material stimulates different areas of your brain. When I'm reading tech material, I'm focused on understanding all the ideas being conveyed. When I read for leisure, I don't have to focus on thinking quite so much.

We've all heard how exercise helps both your physical and your mental condition. Leisure reading helps your stress levels and creative powers. Unless your like me with unlimited creative power, you should take a break and read a book just for fun.

It important to keep up your creative thinking as a developer. Leisure reading is a good way to do that, and enhance your job performance. Besides, many overworked geeks need a little break sometimes. We encourage it among our team. Your reading list should be a dash of technical and a pinch of non-technical material.

-j

What makes a system hard to work with?

Quick link: Jeremy D Miller hits a home run. Linking this because its relevant to my 'for humans' series and what I'm getting to with it.

Unit Testing is for humans

Audience note: this is written for non-programmers or beginning programmers. Don't skip it though, it lays out reasons why unit testing is good. Should also be witty and entertaining. I've been practicing this at the Improv. ;)

When I was a kid, I had one of those AM radio kits that you build yourself. My dad told me a little about electronics, and with the instructions I tried to build it. Several times. I would get to a point where I thought it was done, and put it all together. Then I'd find something didn't work or wasn't right. So I would have to take it apart again and try to figure it out. After doing this a few times, I realized it was easier to check the soldering, wires, and knobs as I went along before putting it all together in the cheap case. I got it partly working with a nice, clear static sound before I lost interest and used the parts for something else. It was a good lesson though.

It's a bigger pain to find out later something wasn't working than to take the time right away to check it. In software development, we call this Unit Testing. 

What is this Unit Testing you speak of?

Unit Testing is the practice of breaking software into the smallest logical parts and testing that each small part does what it is supposed to do. This also has the effect of driving you to build pieces that you can test and maintain more easily. Testing your code has some very specific benefits: you know it works. The process of doing this also benefits you by creating a path toward a good application where all those small parts work together well.

Why would I want to do that?

helps with design The resulting design (how things fit together) is naturally easier to maintain and fix. Like water flowing down hill, you can more easily tell where its going and where it came from. This makes following it a lot easier. It also makes changing it a lot easier.

helps solve problems  Sometimes you get stuck on how to build a certain piece. You can write the unit test first, which I recommend anyway, and then start writing code until the test passes. In effect, you are first defining what you want to happen. Then trying to make that happen, and you are done when the test passes.

makes maintenance easier If you have a bunch of tests and discover a bug then you can more easily find and fix the bug. If there is a failing test where the bug should be, then start by fixing the test. If the bug is still there, you write a test that will pass when the bug no longer happens. Now make the test pass. In doing this, you are isolating the part(s) where the bug happens which makes it easier to find. When its easy to find, its much easier to fix.

easier for other dev's to figure out Imagine you just started trying to use that radio I kinda built when I was a kid. You have the manual and a not really working radio. If I had tests to go along with each part, you could check each test to see what it does and make sure its right. Then fix the one (I'm sure it was only one) that wasn't working. Smaller pieces are easier to understand, which is important even if you are an expert with the language its built with. Maybe unsurprising is that it's often your own code. It's easy to forget what you did a few weeks, months, or years ago. Having those tests help.

Why doesn't everyone do that?

never heard of it/don't know about it  This is pretty obvious. You're a new developer who is either self-taught or wasn't taught unit testing in school. You learn, you believe, you test the daylights out of everything forevermore.

takes too much time It's true, sorta. It takes time to add unit tests and it can sometimes feel like its too much time. It will save you time when it comes to fixing bugs or adding features. You will have less bugs, and changing things takes less time because you know immediately if you broke anything.

don't see the point Hopefully you do after reading this far. But just in case, remember the AM radio.

my code is good enough without it It's true some of you and myself have coded without unit testing, and did just fine thank you very much. I remember those days: 80 hour weeks to fix the last bugs before releasing a product. Sleepless nights fixing a broken deployment. Yeah, it was great. But I don't much have to do that anymore. That's partly because of experience, and partly because testing my code as I go helps me find problems sooner.

other people keep deleting my tests anyway OK, I hadn't really heard this one before today. I have some guesses as to what may have happened, but it doesn't really matter. The problem is the team wasn't supporting the unit testing practice. It's hard or impossible to move forward with unit testing in a situation like that. The fix is to have them all read this article so I can tell them how right you are. hehe. Really, discuss why it helps. If this article helps explain that then great because that's my point. 

my app is too hard to test I have a lot of sympathy for this; a big part of my day job is in this situation. The closest we could come is called "integration testing" which is basically like unit testing except we aren't breaking it down into smaller parts to test. You don't get the benefits of real unit tests, but it's better than nothing. Work unit testing in as much as you can and build team support. After that, you have to figure out what's next. Sometimes, it's not even up to you.

Things for your utility belt

MbUnit, nUnit, xUnit are all .Net testing frameworks. They include pretty application to run your tests and show you the results; typically green for pass and red for fail. Everything you'd expect after taking Driver's Ed. class. testdriven.net is a utility which helps make running your test easier. These two powers combine to give you nearly unlimited power less work in building and checking your tests. 

These are a few unit testing tools for the .Net developer. There are so many tools to help make it easier to test your code. It's really a life lesson; check your results instead of assuming the outcome is what you expected. It avoids a lot of problems later on even if its a little trouble right now.

Blah blah blah..

To be clear, I am not a zealot (read with Richard Nixon voice). In fact, I didn't code with unit tests when I decided to learn Ruby on Rails about 2 years ago. I would make a rails app and play around then start over. It didn't really matter because it was just throw away code and I only wanted to see how it worked. Until I stumbled on an idea that was actually useful to me. I've slowly worked on it for the last year since I don't have a lot of time for it; and now its about 90% functional. But no unit tests, which is horrible because rails is big on testing. I may have actually been able to complete it by now if I had unit tests, even if I didn't put any more time into it. Now I have to go back and add them because I know it makes a difference.

Time to get back to work. I'm at a point where I need to write some unit test, and I'm excited.

-j

Mocking Justin Etheredge

Justin Etheredge has started a series on mocking using Moq, which is a mocking library that I've been meaning to learn more about anyway. Here are links for the first two posts. 

• part 1
  
• part 2
  

 -j

Beginning IT careers for humans

A friend recently asked my advice on getting started in IT and how to learn more about it. Being the super generous, ever wise person that I am, I told him to take a flying leap.. just kidding.

It made me think because I wasn't sure how to advise him about figuring out what area of IT he might find most interesting. With current market conditions, jobs aren't jumping up and grabbing you but IT has remained better than others. It's probably not as easy for beginners although now is a good time to start learning. You can check monster.com, dice.com, or even craigslist.org to find IT job postings to see what is going on in the job market. BUT before you do that, you should have an idea of what IT field you are interested in, and the key terms to use in searching for that shiny, new IT job.

Pick your flavor

There are quite a few different areas within IT, and Ill name a few. Readers, feel free to comment on any I missed or add details you might give to a friend.

Hardware

    If you like building and putting things together, this might be a good area for you. It's an engineering discipline, but is often combined with the resposiblities of purchasing and tracking assets.

Networking

    This area involves the wiring and connection issues involved in computers talking to each other. It can be for office networks, or meeting communication needs of a high traffic website. It's often rolled up in a hardware position, but both could turn into a high end specialist.

Help Desk / Support

    This is usually helping people solve their problems.  Could be on the phone or in person, but you really need people skills and patience for this field.  A few different paths for this might be internal help desk for a company, help desk for other companies, or contractor who supports local businesses.

Software Testing

    If you like to mess around with programs and figure out how to break things, you'll probably do great and have fun in this area.

Software Development

    It's what we do. It's mainly divided into two areas: Internet/websites, Installed programs (like Mircrosoft Word ot some other programs.) Problem solving is a must, but so is creativity.

Database Development or Management

    The art of managing and manipulating data can be consider it's own special discipline; especially when it comes to dealing with very large or high volumne databases. It's not for everyone, and the only way to figure it out is to try it. Start learning programming and pick projects that use databases; that will introduce you to it. After that, you'd need to read topics specific to database development or management.

Project Management

    Organizational skills. After that it's a mix of different things, and sometimes you might be asked to fill other roles (like Help Desk or hardware)

Product Analysis

    This is making the business rules for software. People skills, creativity, and some knowledge of software will serve you well.

There's a variety of combinations and things are always changing. With so many different tools, languages, and technologies, I couldn't list nearly enough in a reasonable amount of space. Pick which area you like, then start learning about the specific technologies in that area.

It's important to be a good problem solver, be comfortable learning, and have good communication skills. After that, there's a lot to say for experience and determination.

Add your mix-ins

So how do you get started? Well a degree certainly helps and so do professional certifications, but I'd suggest trying some of these before committing. There are plenty of entry level tutorials online. Use a search engine to find them by searching for "tutorial " and your keyword like "website programming". If you're not already aware, there are many different programming languages so start with a common, object-oriented language if you are thinking of going into development. We use C# and Ruby a lot. Java is another good choice.

Even if you don't find a free course or podcast, you should look for an inexpensive introductory class. You don't want to commit a lot of money until you know what you are getting into. I recommend online sources because it is easier to fit into your schedule.

Once you've got a good idea what you are interested in, talk to friends if you know anyone in the industry. Try local user groups or online groups. AZGroups is a local .Net User group with friendly, helpful people. I use Google Groups quite a bit myself for discussing IT topics, and helping people find answers when I can. (Email me if you want suggestions for groups in the Phoenix area.)

If you are truly committed (and being committed to a mental health institution is a requirement for some IT jobs), then go get the training and basic skills you need. There's no reason to spend a lot either. Look at community colleges or certification programs. Being a good problem solver, learning fast, and communicating well is more important that a degree or certificate. Those just show your commitment and some presumptive, basic level of ability.

Lets roll

The next step is landing that first job. As with any job, networking helps a lot. Try LinkedIn.com, which is a professional social networking site. Go back to those friends and user groups you talked to. Check those jobs sites I listed above, and search for others. There are many more than the ones I listed. Even though I'm a seasoned professional, I've been known to go door-to-door in search of work. (There's a good story there which maybe I'll tell later.) You do what it takes, and it usually works out. Especially if you are passionate about your choice.

Blast off

After you've gotten some experience built up, you'll find it easier to pick where you want to go with it. Let's say you become a website programmer and you love cars. Perhaps you build a website focused on small track car racing and earn money selling ads. You'll love it and it pays the bills. Or maybe you land a programming job with an autoparts retailer, or something else related to your passion. Who knows. What I do know is things work out best when you stick to what you like; and the best ideas are ones you would love yourself. Passion is the key to happiness in any career, and is especially true in IT. 

-j  

An MVC Argument for Humans

MVC is all the rage it seems. I really didn't get it at first; that is until I started using it. That was a few years ago. Now it's my prefered pattern for web development. It wasn't originally a web pattern, but it turns out to be a great way to keep things clean in a web application. It's a good convention, in my opinion.

Now it's not always the best choice. It depends on your needs. It certainly takes extra work if you're going to build it yourself, but chances are you don't have to. Several frameworks have sprung up to fill that void. Probably the most famous is Ruby on Rails. It's obviously for the Ruby language, and there are others out there for Ruby. There are frameworks for PHP, Java and .Net as well.

We mostly work with .Net (with a dash of Ruby) so let's talk about that for a minute. In my opinion, there are 3 major MVC frameworks for .Net.

• ASP.Net MVC
• Castle Monorail
• Promesh.net

ASP.Net MVC is Microsoft's mvc framework. Castle Monorail is part of the excellent Castle Project, an open source project. Promesh is another open source project, which came from a developer's personal toolbox out or real world use. I'm more familiar with the first two. We use Monorail in our project, so have a little bias. (computeristsolutions.com is built with monorail for example)

Convention

So how often do you look at an old project or old code and think "What was I doing here?" or "What the **** was the other guy thinking? What a moron!" It happens. Sometimes I'm the other moron. It's easy to forget what was going on as time passes. Sticking to a convention helps avoid that. You know the convention, you can follow the code a lot easier. You can find where things are at. Easier maintenance is a big deal, and MVC helps with that. A lot.

Testing

Do you test your code, unit test perhaps? You should. Go. Do it. Now! There are lots of reasons to use unit testing, and its not really my point in this post.. but let's leave it at you KNOW your code works when you commit it to source control. MVC helps and encourages seperation of code so that testing is easier. By doing so you will be able to more properly, fully, and completely test your code. (Also look at Inversion of Conntrol; look at Castle Windsor) The function of a unit test is to test a small unit of code. If everything is lumped together then testing small units gets hard or impossible. It just so happens it makes maintenance hard too.

Design

This isn't really talked about in most MVC articles I've read, but it really is a big time savings in our experience. When you build and maintain a website, you will have to alter or completely change the design and layout. If you're using a MVC framework, it's a lot easier. You typically have a central layout which is used for all or most of your pages. You only have to edit that one layout to change most of the site. If you were careful to make everything CSS friendly, then you have even more power over your site by changing the layout and/or the CSS. Even when a plain HTML site would be fine, I lean towards using an MVC framework for this reason. Site-wide layout and design changes take minutes instead of days or hours.

Conclusion

Hope this brief, humanized argument for MVC on the web makes sense. There are many good choices for frameworks. We recommend Castle, and the upcoming ASP.Net MVC framework looks pretty good. There is a small learning curve in adopting it, but it will payoff big in time and headaches saved. If you need to adapt your current ASP.Net site instead of writing a new one, I'd suggest looking into the MVP pattern. See MVP here, here, and here. Good luck and have fun, which I'm sure you will.

-j