software solutions / project leadership / agile coaching and training

Responsible software development

Posted on September 25, 2013

How much of the responsibility for the software that you are creating falls on your shoulders?

There are two ways of looking at responsibility on a team. One view would be to say that if there are 10 people on the team, then I’m responsible for 10% of the software development process. I don’t need to be concerned with the quality of the requirements because that’s the business analysts’ job. I don’t need to worry about testing my code because we have testers to do that.

The other view is that even in a team environment, I am still 100% responsible for the software I’m creating. That means that I’m not just implementing the requirements, I’m trying to understand the requirements to make sure that they’re correct and that we’re building things in the best way possible that will meet the needs of the business. And that certainly means that I’m never ever going to send code to QA that I haven’t tested just because I think they’re going to test it for me.

I need to be responsible for communicating with my team members the best that I can. I would much rather be clear about who is doing what rather than assuming. If I make an assumption, it’s probably going to be wrong – either I will assume someone is going to do something when they’re not and something will slip through the cracks, or I will assume someone is not going to do something when they are, and now we’ve duplicated effort.

This is what I see happen often on software teams, especially when it comes to testing. Developers assume that QA is going to do the testing, so they give code to QA without completely knowing if it’s working. QA assumes that developers are going to do this and don’t know what was tested and what wasn’t, so they think they have to test 100% of the functionality of the feature. In reality, the developer probably wrote decent code that mostly works, and they probably did test it to some extent (whether manual or automated), so the tester is duplicating some of the effort, but if they don’t know what was already done, they don’t have a choice.

This is where communication is key. If I as a developer am going to write automated tests to prove that my code works, then I want QA to be involved in the writing of the tests (even if that’s just reviewing what I’m doing). That way QA doesn’t have to duplicate effort because they can know that developers have already done some of the testing, and developers can start giving code to QA when they are confident that it works (with actual proof to back it up). QA and developers can work together to decide who is going to test what, what is going to be tested, and how it’s going to be tested.

In this case, everyone is 100% responsible for the quality of the software. Instead of expecting others to cover for us, we work together with others to make sure everything is covered. This requires people to move past their traditional roles, trust each other, and work together. In the end, we won’t duplicate effort and we won’t let things slip through the cracks.


Posted on September 24, 2013

Do you sometimes have that feeling that your life is running you instead of you running your life? Do you feel so bogged down with meetings and distractions at work that you feel like you’re unable to get anything accomplished? Are you feeling like you don’t have the discipline to accomplish your goals?

The answer to all of these questions involves focus. I firmly believe that I need to have a plan for achieving my goals and getting things done so that I can be in control of the situation rather than have the situation control me.

Focus at work

Most of feel (or have felt) that we have too many meetings and distractions. I’ve certainly felt that way a lot in the past. I’d like to tell you to just start skipping meetings, and while that might be a good idea in some cases, most of the time you can’t do that. What you can do is prioritize meetings and distractions so that you have time for the most important things.

If I’m working on a project, people expect me to get things done. So if all of my time is consumed by other things like meetings, production monitoring, asking questions, etc., then I’m not sticking to my promises. I started blocking off work time on my calendar. Actually our whole team blocked off 3 hours in the afternoon for “work time”, and if my day got to be half full with meetings, then I would just block off the rest. I decided that I needed at least half a day of time to get things done because that was important. I wasn’t dismissing everyone else, I was just making a conscious effort to decide what was most important.

I’ve also been getting better at saying no. Even if I’m not feeling swamped by deadlines and meetings, I still have a primary task that I’m focusing on. In order to maintain that focus, this means that I’ve started saying no to other people who need things done if I’m not the person who should be responsible for doing the work. I generally like to help people, so it’s been hard to do this. I’ve even started doing it with relatively easy tasks. Sure, I could spend 20 minutes and get that thing done for someone, but then they will keep coming back. This sounds somewhat selfish, but I’m making a conscious effort to focus on my task at hand.

Focus in life

There have been times when I have felt like my life was running me and that I was just treading water and trying to keep up. No one likes feeling like this.

I realize that I’m only somewhat in control of my life. I could get cancer tomorrow, or get hit by drunk driver. Thankfully those haven’t happened to me so far, so I want to proactive and intentional whenever I can.

The first thing to do is decide what you want your life to look like and then come up with a plan for success. Then you need to arrange your life and activities around those priorities. Time is a scarce resource for all of us, which means that at some point we have to think about what’s filling our day and eliminate things that aren’t important. With all of our electronic devices, it’s so easy to spend more and more time surfing the internet, reading blog posts, playing online games, and so on. Not that those are bad, but I’ve found that I need to cut some of those out so that I have more time to do the more important things I need to do.


Posted on July 16, 2013

This is not your typical technical blog post.  It’s about something I’ve started doing personally to increase my productivity at work.  And it’s been around since the beginning of time.


It started because I had a 5 week old baby at home, so I would occasionally be a little more tired than usual at work.  We have a room at work with a recliner, so I went in there, closed the door, turned the lights off, and took a 15 minute nap.

When I got up… wow.  I felt like my eyes were so wide open that people were going to look at me funny walking down the hall.  This was better than caffeine.

I now have a 7 week old baby at home who is nice enough to sleep through the night now, so I’m getting back to my normal sleep schedule at night.  But most days I still take a nap.  All it takes is 15 minutes and the lunch coma is gone.  Afterwards I find that I’m thinking so much clearer, and I generally do things much faster than before I rested.

I’ve always joked about how work would be so much easier if I could take a nap in the middle of the day.  I guess it actually works.

Are software teams inherently inefficient?

Posted on July 8, 2013

I recently went through a big change in my role at work. I went from being a tech lead on a team of 15 people to working on a project all by myself. 

Anytime you go from one extreme to the other, you see some stark differences between the two environments, and in my case, it caused me to think about the way we do things in teams.

The most obvious change was a huge decrease in meetings.  I went from an average of 4-5 meetings a day (not counting standups) to an average of 1 meeting a day. When you’re a team lead of a large team, I suppose that comes with the territory. But when you have close to 7 hours a day of time to work with minimal interruptions, you get a LOT of work done.

Meetings are a common complaint from people who work in a team environment. And even though you can read hundreds of articles about how meetings are pointless and you should skip them, the fact is that most meetings exist for a good reason, and while skipping all your meetings may seem like a good short term decision, you can’t realistically do that all the time.

I think that the problem isn’t necessarily the meetings, it’s the fact that the meetings are needed in the first place. Every time you add a person to a team, you’re introducing more inefficiency to the team because now there is one more person that you need to communicate with, that you have to share information with, that you have to invite to a meeting.

Now, even though this inefficiency exists, typically you are adding someone to the team because the benefits of having them there outweigh the negatives. But to what extent? Is there a point where you get diminishing returns from adding new people?

Managers exist for a good reason – to coordinate team activities, make sure everyone is on the same page, communicate with other teams, and go to lots of meetings so that the rest of the team doesn’t have to. When your team gets really large, you start needing more management. Then what happens is one of two things – the manager becomes overworked and can’t keep up with everything, or you end up having your tech leads go to more meetings and become more like managers. The problem there is that tech leads are tech leads because they’re good at tech, not necessarily because they’re good at management, and now you’ve essentially taken your best technical person and removed them from the role where they can provide the most value. Then your tech leads get frustrated because they feel that they don’t get anything done because they spend all of their time on meetings.

If you’re hiring a bunch if people and creating a big team, it’s probably because you have a lot of important work that needs to be done, so I’m not saying to not hire those people. But I would encourage you to find a way to split them up into smaller teams. You may have multiple teams working on the same project or even in the same codebase, and that’s fine, we just want to decrease the amount of communication that is needed in order to get things done.

Our IT department has done a lot of this lately, trying to take large teams and divide them up into smaller sub-teams of around 4-5 people. Now those communication inefficiencies are diminished because you only have to communicate with a few people (who ideally sit in the same area as you). Not only that, planning is so much easier. It’s much easier to accurately predict what you can do with 4 people than it is with 15 people, not to mention that if things go off the rails for an iteration, it’s a lot less expensive.

I think the ideal team size would be 3-5 people, where you don’t have more than 2 people in each discipline (BA, QA, dev). It would be even better if those people were somewhat cross-functional so that they can help each other out when someone gets behind.

While splitting into smaller teams may make those teams more efficient, you still will need coordination across teams and more meetings and management. But I think having smaller teams helps you to see the need for management and enables you to put the right people in those roles instead of just pulling your tech leads in to fill those roles.

There are no hard and fast rules for this sort of thing, and the results may be different for you than it was for me. The important things is that we constantly evaluate how we are doing things and find ways that we can increase our efficiency and reliability of our software teams.

A NoSQL Hypothesis

Posted on April 9, 2013

Software developers are notorious for falling in love with new, shiny things. I always try to use the right tool for the job, whether that’s new or old technology. But every now and then I find something that makes a whole lot of sense in my head and I can’t ignore it.

I’ve been learning about NoSQL databases for the last year or so mainly because there’s a lot of noise about them and I was curious, and I also find data access to be this annoying problem that always seemed to be harder than it should be. First I looked into MongoDB and then eventually RavenDB. I haven’t used either of them in production yet (although I work with people who have), which is why I titled this article a “hypothesis” because I don’t really have any real life stories to tell to back up what I’m going to say.

In my research of NoSQL databases I noticed two particularly interesting things:
1) I find that ORMs make data access with relational databases much easier in most cases over using stored procs for everything, but even with all of the experience I have with various ORMs, data access is still a pain.
2) Ayende Rahein was one of the main contributors to NHibernate for years, and he probably understands ORMs better than almost anyone in the world. And yet even he decided to create RavenDB and move to NoSQL. If the ORM expert decides that using an ORM is too hard, maybe he’s onto something.

Here’s how I see it: relational databases are really good for reporting and querying, but not so good for loading information in an application. NoSQL databases are really good for loading information in an application, but not so good for reporting and querying.

The application I’m working on is 2 years old now and we use SQL Server. We are starting to accumulate a lot of data in the database, which is exposing performance problems in our application and everything is starting to process a little slower as we get more data in the database. Our database is not good at loading information in the application (it takes a lot of queries to load up the main screen because it has to query so many tables).

We are also starting to move away from reporting against our database now and moving more data into our business intelligence data warehouse so that our reports can run faster and be written against a relational schema that is optimized for the types of reports that we tend to write.

So let’s recap.

1) Our app is not good at loading data into the application using a relational database
2) Our relational database is not going to be used for much reporting and querying because we’re going to move the data into another database for that purpose.

So with that in mind, why am I using a relational database? Shouldn’t I be optimizing for the loading and saving of the primary objects in my application since that’s my pain point? (I haven’t even started talking about the increased in developer productivity from being able to do more in the business layer and less in the data access layer and stored procs.)

I’m not saying that I’m going to switch my application from SQL Server to RavenDB, because I don’t know that it would be worth the time at this point. But if I were to do so, I would be able to delete a slew of complicated stored procedures and turn my data access layer to a really really thin layer than essentially just passes a C# object to RavenDB. I would be able to load, modify, and save our primary object (and all it’s children) with 2 database calls instead of over 20 (in some cases). If I use RavenDB, there are built in mechanisms to write triggers that will take updates from RavenDB and replicate them to a relational database.

When people start a new application, it’s just assumed that they will use a relational database. But why? Is a relational database really the best data store for every application? Given that we have good NoSQL alternatives, maybe it’s time we start evaluating all the options.

I’m sure it’s not all rainbows and unicorns, and in some ways you’re just trading one set of problems for another. Dealing with large amounts of data is never easy. But I’m seeing a lot more solutions than problems.

More AutoHotKey goodness (database edition)

Posted on February 28, 2013

I posted a few years back about some of the macros that I have in my AutoHotKey file. Since then I’ve added some new things that are worth mentioning.

Inner joins

The project that I’m on involves a lot of database work. I’m writing queries all the time, and this means typing the same inner joins over and over. I would rather let AutoHotKey do that for me.

Here’s a query that I write often:

select * from igs.accounts a
inner join igs.enrollments e on e.accountid = a.accountid
inner join igs.intentions i on i.enrollmentid = e.enrollmentid
where a.utilitylineofbusinessid = 5

It’s incredibly painful to type those inner joins over and over (it was even painful writing it for this blog post), so I use AutoHotKey to do it.

:*:ea]::inner join igs.enrollments e on e.accountid = a.accountid
:*:ae]::inner join igs.accounts a on a.accountid = e.accountid

:*:ie]::inner join igs.intentions i on i.enrollmentid = e.enrollmentid
:*:ei]::inner join igs.enrollments e on e.enrollmentid = i.enrollmentid

:*:wcpa]::where utilitylineofbusinessid = 5

SendEvent select * from `

So now to type that same query, here is what I type:

ssf]igs.accounts a

I have macros for virtually every inner join I would ever do in the database so that I don’t ever have to type one out. If I find one that I missed, I go back and add it.

This makes writing queries so much easier. Once you find ways to do mundane things faster, it makes you do everything faster because your typing is keeping up with your brain.

Switching databases

We have several database environments just like most of you, which means that I’m switching between database servers all the time in SQL Server Management Studio. Again, I can pick up the mouse and click 5 times in dialogs and toolbars to switch. Or I can do “Alt-q ch Ctrl-u i”. But I would rather do it with one keystroke.

Send !qch
Send thedatabaseserver
Sleep 200
Send {Enter}
Sleep 100
Send ^ui{Enter}

Boom! Ctrl-Win-1 and I’ve switched to my database server and selected my database (the “Send ^ui{Enter}” line does that – Ctrl-U selects the database dropdown and “i” selects my database because my database name starts with “i”). I have shortcuts for all of my database environments so that I can do even less with the mouse than ever.

Commonly used queries

There are certain queries that I use a lot (e.g. select the top 1000 rows from our log table). So I wrote a macro for that.

:*:seq]::select top 1000 DateCreated d, * from igs.ServiceExceptions order by DateCreated desc

Typing is slow

Typing is slow (and I’m a faster typist than most), so anything repetitive that I do often I want to turn into a macro or keyboard shortcut. Hopefully some of these ideas will give you ideas of how you can improve your productivity.

The Human Side of Software Craftsmanship

Posted on January 29, 2013

The Manifesto for Software Craftsmanship states that they “are raising the bar of professional software development by practicing it and helping others learn the craft.” As a software developer, I take pride in my work and have high standards for myself, and I appreciate it when others do the same. But if those high standards turn into arrogance toward others, then maybe we’ve gone astray.

They told us back in grade school that you shouldn’t pull yourself up by putting others down, but even today that wisdom can be hard to remember. I admit that I’m guilty. If you work at a company that has any code that has been around for a few years, you’re going to find some horrible code, and it’s really easy to make fun of it. I still do it all the time, but I’m trying to stop.

Arrogance and software craftsmanship don’t mix. While the technical aspect of software development is extremely important, the human side of things is just as important. It doesn’t matter how good your code is if the software doesn’t meet the needs of the users. If you refer to people in the business as “stupid users”, how are you going to be able to understand what life is like in their shoes? If you know all of the SOLID principles but you have a bad attitude, your teammates would probably rather work with someone else.

People who don’t know what we do sometimes think of software developers as a bunch of people who sit in front of a computer all day and never interact with anyone. In my experience, that hardly ever happens, and in fact, we often get rid of cubicles in favor of more collaborative workspaces where we can communicate easier with other team members, and sometimes even have business users come sit near us so that we can have their constant feedback.

I remember a situation several months ago where I had to meet with some users to design some functionality. After the first few meetings, I had to present a potential design idea to them. Before I went into the meeting I had already thought of potential issues that the users might bring up and the rebuttals that I would give. The users expressed some concerns and I wasn’t winning them over.

I stopped after that meeting and took a step back. Maybe I was listening to the words coming out of their mouth but not actually hearing what it was that they were really saying. Maybe their concerns weren’t petty after all and they had good reason for bringing them up.

The next time we met, I tried to go in and just listen. I mean really listen, like let them talk without thinking about what I’m going to say next. I tried looking them in the eye and processing every word that they say, the feelings they were expressing, and the reasons why they believed that way. Then when they were done talking, then I would think about how I’m going to respond. And this time I finally saw what they were talking about. It really hit home when one of the users (who was excited about me finally getting it), said excitedly, “That’s what we’ve been saying for the last month!”

I’m glad that I finally got it right, but I’m disappointed that it took me so long to get there.

In my mind, in order to really consider yourself a craftsman (or craftswoman), we need to not only value technical expertise but skilled human interaction and communication skills, and that starts with having an empathetic attitude toward others instead of finding ways to put them down.

Controlling your time

Posted on January 28, 2013

We all have numerous activities and people competing for our time. More than anywhere else, this seems to play out at work.

If you’ve ever had a day full of meetings, you know what I’m talking about. It feels like you go to work for the entire day so that other people can get stuff done while you feel like you accomplish nothing.

A day half full of meetings isn’t much better, especially when the meetings are scattered throughout the day. Sure, you technically have half of your day to get work done, but it’s constantly broken up by meetings.

We came to a point on our project where this was getting really bad, especially for developers. We would often spend half of our days in meetings, and as a result we wouldn’t have any long stretches of time to focus on writing code. We had to do something about it.

So we did. We blocked off 2pm until whenever you left each day for no meetings. We acknowledge that meetings are necessary, but we need to set aside time for ourselves so that we can get the things done that we have promised that we would get done. This is an actual calendar invite in Outlook, so the time shows up as busy to anyone trying to schedule a meeting.

We also blocked off 10am-11am every day to have meetings. When we need to schedule a meeting, we try to fit them in between 10-11. We have our standup at 10, so we’re already stopping for that anyway, so it’s a good time to talk.

The Results

This system has been awesome. I often have meetings from 10-11, and sometimes longer, but if the 10-11 slot is full, people will schedule meetings in the time slots around it. As a result, I’m often done with meetings for the day by lunchtime. I have close to the same amount of meetings as I did before, but now I get them all over with at once. Now I have the whole afternoon to get work done. This has done wonders for our sanity.

Since we don’t have many time slots for meetings, this forces people to not schedule frivolous meetings. You know the ones I’m talking about, where someone schedules a half-hour meeting for what ends up being a 10 minute conversation. Now we just have a 10 minute conversation after the standup.

There is a real cost to context switching. It takes some time to get in the zone, regardless of whether you’re writing code, writing requirements, or testing. Every time that you have to stop what you’re doing to do something else, you need to spend time to get back into what you were doing.

In the end, it boils down to being in control of your schedule so that you have time to do the things that are most important. I encourage you to set up whatever boundaries you need in your day in order to help you succeed.

A culture of empowerment

Posted on January 24, 2013

Much has been said recently about companies like Github, Valve, and other places that create these open corporate cultures of empowerment where employees can do pretty much whatever they want. This manifests itself in many different ways, from allowing employees to work where they want when they want to allowing them to even decide what they want to work on and not limiting their time off. A great example of this is Valve’s new employee handbook. Stop reading this post and go read the handbook, it’s worth the read.


Hey, welcome back. How do you feel after reading something like that? It gets you a little excited, doesn’t it? Personally, I love the idea of getting to move my desk wherever I need to, or being able to decide what I want to work on. In a place like that, there’s no limit to what you are able to accomplish. You are only limited by your own abilities and time.

Let’s be honest though, most of corporate America can’t be as free wheeling as a video game company. When I go to work, I’m doing work for people who tell me what project to work on, and they get to decide what projects are most important to them. That’s the nature of the company that I’m working for, and there’s nothing wrong with that.

I care more about the principles behind these empowerment cultures. The main theme that I see is that they hire awesome employees and then let them be awesome. How many times do you hear about developers who feel like that can’t be as successful because their team lead or manager won’t let them use a certain technology or framework or technique? Maybe those people feel like their control is doing good (and maybe it is), but the trade-off is that they are stifling their top performers. In that case, the side effects might be worse than the perceived decrease in risk.


Since most companies don’t have an empowerment culture, there must be a reason.

It is really hard for people in control to give up control. Say you’re a manager, and your lead developer comes to you and says that he wants to use MongoDB instead of SQL Server on his new project. Immediately you think of reasons why it’s not a good idea (Our infrastructure team doesn’t know how to host it properly! Our DBAs don’t know how to use it! What about reporting?). Those are all important questions that need to be answered, of course, we don’t want to be reckless. Ultimately it comes down to a choice – you can choose the safe option (SQL Server), or the more unknown (MongoDB) which might have some new challenges that you need to work through, but also might provide developer productivity increases, better application performance, and increased morale of the team.

If you don’t let top performers be top performers, why do you have them? If you stifle them, you are losing out on one of the main reasons you have them in the first place! If it lasts long enough, they will leave and try to find another place where they might be able to use their skills.


It takes a lot of guts for a manager to give up control. If that manager were to let his developer go ahead with MongoDB, that would take a lot of trust. He’s basically putting the project at risk (maybe not really, but in his mind) and placing a lot of trust in his development team. And you know what, it might fail.

But let’s be honest, if we can’t trust our development team, why do we have them? Why don’t you just get rid of them and have the managers and architects do the work? Are they really the only ones who can be trusted to make big decisions, and even small decisions?


Employees that live in a culture of control often live in fear. These cultures often try to remove risk because failure is seen in such a negative light. As a result, you can’t try new technologies (because it might fail), you have to use the approved enterprise development frameworks (so that we use something that we know has worked last year), and heaven forbid you say the “A” word and want to implement agile practices (because the project managers don’t have as much control). This may keep some projects from failing, but it pretty much guarantees that every project will be sufficiently average.

Do you want to work in a place like this? I don’t.


In a culture of empowerment, you have the freedom to try new things. And since some of those things won’t work, you also have the freedom to fail. When it does work, we all win, and when it doesn’t work, we learn something so that we are better next time. But everyone wins when it comes to that feeling that you get when you go to work believing that you can change things for the better and that you can make a difference. Now I truly have responsibility, because I’m responsible for the success of something and I will be held accountable for my decisions. But this just motivates me to do better.

That freedom is what really gets people excited. When you don’t feel like you have anything holding you back, your mind is free to dream of anything, including those crazy ideas that might actually work. This is incredibly motivating, because now we’re only limited by our team’s abilities and time.

Side effects

There are certain types of people who tend to prefer empowerment cultures. The ones who don’t like it are the ones who want to play political games, have a bad attitude, and are afraid to try new things because they are afraid they might fail. The ones who like it are the innovators, the people who embrace change, the motivated, the top performers. These people don’t just value a salary, they value autonomy, mastery, and purpose. Every company tries hard to recruit these people, but few realize the importance of the empowerment culture.

Practicing what matters

Posted on November 30, 2012

I read an interesting article in the Wall Street Journal the other day about “Must-Have Job Skills in 2013″. While this wasn’t necessarily referring solely to technical fields, it was still interesting. Here is their list of must-have job skills:

  • Clear communications
  • Personal branding
  • Flexibility
  • Productivity improvement

It made me think of the software craftsmanship people and the importance that they place on things like code katas, learning new languages, etc. If you’re a developer and you spend time honing your craft, how much value are you placing on skills like:

  • Being able to write a good requirements document
  • Facilitating a requirements gathering session with business users
  • Giving demos of your software to users (in their language)
  • Coming up with estimates for a large set of functionality
  • Being able to evaluate tools and frameworks and choose the best one for your project

Admittedly, it’s much easier to practice TDD than it is to practice requirements gathering. But these are skills that I feel are very important for developers. There are lots of people who can write code, even good code. If I don’t know how to use a language or framework, someone can teach me pretty quickly and I’ll pick it up. But can you also pitch in and help with requirements gathering, test planning, system architecture and design, and everything else that needs to be done on a project? Now that will set you apart.

When you think about learning new skills and investing in your career, just make sure that you don’t limit that to tools and technology.

« Newer PostsOlder Posts »
I have over 10 years of software development experience on several different platforms (mostly Ruby and .NET). I recognize that software is expensive, so I'm always trying to find ways to speed up the software development process, but at the same time remembering that high quality is essential to building software that stands the test of time.
I have experience leading and architecting large Agile software projects and coordinating all aspects of a project's lifecycle. Whether you're looking for technical expertise or someone to lead all aspects of an Agile project, I have proven experience from multiple projects in different environments that can help make your project a success.
I believe that Agile processes and tools should be applied with common sense. I've spent the last 6 years working on Agile projects as a consultant in many different environments, both in leadership roles and as a practitioner doing the work. I can help you find out how Agile can work best in your organization, not just apply a prescriptive process.
TDD Boot Camp is a hands-on, three day, comprehensive training course that will teach you all of the skills, tools, frameworks that you will need to use test-driven development to develop real world .NET applications. If you're not looking for something that intensive, check out the the half-day version.
Have any questions? Contact me for more information.
The Business of You: 10 Steps For Running Your Career Like a Business
From CodeMash 2015, Stir Trek 2014, CONDG 2012
From Stir Trek 2013, DogFoodCon 2013
From Stir Trek 2012, QA or the Highway 2014
(presented with Brandon Childers, Chris Hoover, Laurel Odronic, and Lan Bloch from IGS Energy) from Path to Agility 2012
(presented with Paul Bahler and Kevin Chivington from IGS Energy)
From CodeMash 2011
An idea of how to make JavaScript testable, presented at Stir Trek 2011. The world of JavaScript frameworks has changed greatly since then, but I still agree with the concepts.
A description of how test-driven development works along with some hands-on examples.
From CodeMash 2010
From CodeMash 2010