TDD for Fun and Profit! November 7, 2008
Posted by Mark Hoffman in Tech Stuff.add a comment
There was interesting discussion on Joel On Software regarding the usefulness of Test Driven Development. There were some interesting comments posted such as:
- “Test Driven Development is a huge scam”
- TDD “vastly increases the amount of time to program anything without any benefit.”
- Having developers produce unit tests that cover “even 50% of their code is ridiculous and wasteful.”
- Asking developers to provide large amounts of test coverage is “like asking the fox to watch the hen house”
- Unit tests should be “written by professional QA Engineers”
My first reaction to TDD was “More ivory tower academia from people who spend more time thinking about software than actually writing it” and I dismissed it. But I kept hearing about it and noticed that people that I respected were discussing it a lot more. I finally took a deeper look into it and though confused at first, I began to see the benefits. After a few TDD sessions, I became a believer when I saw the quality of the code that was produced. Today, I still consider myself a TDD newb, but I definitely understand the value.
The reason that I see the value is that it solves a business problem for me. I’m not some techno wunderkind who salivates over the latest flavor of the month. I love developing software, but I’m pragmatic: I want to make money. (See: Capitalism) I take a serious look at anything that can help us produce better, more maintainable software faster. Although our software has always been pretty stable, we had plenty of incidents where having decent tests would have saved my bacon. I quickly found that writing unit tests on existing code was often tricky because the code itself was inherently un-testable. This was a problem. I couldn’t easily write automated tests so my choices were lengthy manual test procedures or just rolling the dice and hoping the code didn’t break.
So for me, TDD was a step towards solving that problem. Today, our new development reaps the benefit of TDD and I’m quite happy with the result. It works for me. YMMV. If TDD isn’t working for you, what type of testing is?
Incremental Improvements October 15, 2008
Posted by Mark Hoffman in Tech Stuff.Tags: CruiseControl.NET, Migratordotnet, TreeSurgeon
4 comments
There are quite a few things that I want to do differently here at AutoRevo. However, I can’t just stop all development while I build the environment that I want. That would be a profit-limiting move…So we make incremental improvements in key areas as we go. This month, we’ve made two key improvements: We’ve implemented CruiseControl.NET and migratordotnet. I’ll have more to say about migratordotnet soon, but I wanted to talk a bit about CruiseControl.
I’ve been wanting to implement CruiseControl for years now. But there was always something else to be done so it go pushed to the back burner. Bad idea. I wished I had implemented this when we started. Beyond it’s stated purpose of making sure everything will build, implementing CC.NET provides other benefits. For example, one project that I added had about a hundred unit tests, but several of these tests were failing. And nobody knew. Everyone ran their individual tests during development but nobody was running all of the tests. Granted, that shouldn’t have been allowed to happen. But now with CC.NET, those tests are all run automatically upon a check-in. And now everyone sees that the tests are failing. No need to depend on a human process to check the tests.
Another benefit of installing CC.NET was to make us think of a better way of handling our project directory structures. A few months ago in preparation for getting CC.NET installed, Sean Scally took some time to research various ways of improving our directory and source control structure. He came across TreeSurgeon and we’ve been very pleased with it. If you haven’t looked at TreeSurgeon yet, I highly recommend it. It’s a great tool that will create a project directory structure, a solution that contains your domain DLL, NUnit test project and a NAnt build script. Best of all, you can download the source and change it to your heart’s content.
What type of things are you doing in your shop to make incremental improvements? I’d like to hear about your experiences!
NHibernate Learnings: Part I October 3, 2008
Posted by Mark Hoffman in Tech Stuff.Tags: NHibernate
add a comment
So we deployed an updated version of our app Wednesday night, and part of that rollout included some NHibernate bits. Rollout went smooth, everything worked just fine. Or so we thought.
Thursday morning I was demo’ing some portions of the app to our Support staff when the application became unresponsive. Within a minute, it was clear that IIS was no longer responding. Ack! A quick look at the server showed that the IIS worker process had in fact died. A quick, but very inconvenient, IISReset command and everything was working again.
I meant to look into the cause of the crash, but got busy doing other things. Then, later in the day it happened again. At this point, it was clear that something with our rollout was causing a problem because IIS had never experienced crashes like this before. Our lead developer looked into it and found that IIS was slowly leaking memory and eventually crashed when it ran out.
A few Google searches later and we found the source of our problem: Our use of the NHibernate session factory. What we were doing was creating a new session factory each time we needed a session. As we quickly learned, this is very much frowned upon and will cause memory to disappear faster than your shares of WaMu stock.
The solution was simple: Wrap the session factory in a singleton and keep that sucker around. Lesson learned!
AutoRevo is hiring additional developers September 25, 2008
Posted by Mark Hoffman in Business Stuff.Tags: Hiring
add a comment
We’re looking for additional developers here at AutoRevo. We’re a small company (around 20 employees) based in Dallas. We offer a casual and sane environment and take pride in our dedication to continuous improvement.
What we’re looking for is a developer who takes pride in their work, is dedicated to learning and improving themself and can work well on a team. Some of the things that we value are test driven development, pair programming when necessary, domain driven design and building solid, testable code in a reproduceable way. No death marches, no mandatory overtime, no insane schedules.
If you also value these things and have a solid background in C# and ASP.NET and are in the Dallas area, then we’d love to hear from you. I can be reached at hoffman@autorevo.com
Agile in Action September 23, 2008
Posted by Mark Hoffman in Tech Stuff.Tags: Agile, Pair Programming, TDD
2 comments
We’ve been slowly adopting Agile practices over the past year or so and have witnessed solid improvements in code quality and productivity. However, some of the tougher parts of Agile for us have been test driven development and pairing. TDD and pairing just doesn’t feel natural at first and it’s taken us a while to get a better feel for it.
However, yesterday was one of those days were everything just clicked. Two of our developers started off in the dev conference room outlining some initial class designs and thinking through some initial code. They hit a few sticking points and asked me to come in for another opinion. We talked about their initial design for a bit and I suggested that they had enough of a design to start writing some tests. There was the usual “what about this?” and “we don’t know how this will work yet” comments, but there was agreement that they were getting diminishing returns on talking about it and it was time to write some code.
So after lunch they paired up and wrote their first test. The code they wrote to pass the test was done in the most basic and simplest way possible. They then refactored. And wrote more tests. And refactored some more. By the end of the day, I checked in with them and they showed me some pretty impressive code that had a solid design and great test coverage.
The code that was written was cleaner and more elegant than the code that any of us had originally discussed during our brief design meeting. In our design meeting, we had thought of doing it one way but the final version was completely different. And better. That’s one of the huge advantages of TDD: We let the tests drive us to a better design. Rather than trying to force fit our preconceived notions into the design, we allow the tests to become the basis of the design. Many people a lot smarter than me have written extensively on this topic, so I won’t bother to repeat it all here. But suffice to say, TDD is something worth exploring if you want to improve the quality and testability of your code.
Pairing also paid dividends. Both of the developers agreed that the code that was written was better than what either of them would have written independently. It’s an example of the whole being greater than the sum.
Adventures in packaging..but not that kind of package September 13, 2008
Posted by Mark Hoffman in Tech Stuff.add a comment
A few years ago, if you had asked me about software packaging or package design, I would have just assumed that you were referring to the little cardboard box that software ships in. (Or maybe even that hideous package design that Microsoft inflicted upon users of Vista and Office) I never really considered that packaging can also mean how we logically separate our software into modules and assemblies.
I know now. Largely due to the fact that my ignorance of packaging in the early days of AutoRevo caused a lot of headaches for us down the road. In the beginning, it was easy. Our software was simple and didn’t do too much. We had a web application in one assembly and we had our business objects in another assembly. The business objects, which I cleverly named AutoRevo Business Objects or ABO, contained classes for things like Account, Inventory and some stuff for dealing with eBay.
Even my less astute readers will already see the problem. But I didn’t. Even on that poor foundation, I kept adding stuff to ABO. Much like building a city next to a massive river, an ocean and a large lake, something really, really bad is bound to happen someday. Before long, ABO contained virtually all of our business logic for dealing with accounts, inventory, authentication. dealer websites and a bunch of other things. It also knew everything about launching and revising listings to eBay. It was all knowing and all powerful. A good thing for a deity, but not so much for a single software component.
Unit testing was something that we only paid lip service to at the time and the tests that we did have weren’t very good so the predictable result is that anytime we had to roll ABO, we risked breaking, well, the entire application. And we were forced to roll out the entire AutoRevo Business Objects DLL no matter how simple the change was since it contained everything. eBay changed a rule about revising an auction? Roll out ABO. Wanted to change a minor setting regarding an account? Roll out ABO. My original design decisions were bearing fruit and it wasn’t too tasty.
I wished I could say that all of this was behind us now and that all of our code is a shining example of proper dependency management. But it’s not. We’re still working to break up those dependencies. We’ve gotten a lot smarter and do things a lot differently today, but legacy code is something that always has to be dealt with.
So this week I’m going to be writing about some things that I’ve learned along the way, some metrics that are useful for gauging the health of your packaging and discuss a really cool tool that can be used to help you understand your software dependencies. Hopefully, you can be spared some of the same mistakes that I made.
Make it work the way I think it should September 5, 2008
Posted by Mark Hoffman in Business Stuff, Tech Stuff.add a comment
A bit of rant here…..When building your software, help your users by making the initial configuration choices for them. It doesn’t matter how slick or powerful your configuration system is. Your users won’t care initially. Your users want to first use the software and then configure it to meet their specific needs. That’s why we have default configurations.
We recently purchased Version One’s Agile Enterprise. It’s a great piece of software and we love it. I’ll have more to say on it later, but overall, it is working quite well for us. However, one annoyance is their lack of default configurations for each user.
Case in point: Their software has a nice feature so that a little mail icon appears on the screen when a user receives a message or alert.
Version One Notifications
Cool. “That’ll come in handy”, I thought to myself. While we’re working on a story, we’ll frequently need clarification from our Product Manager. So we add a task to the story and assign it over to him. My clever plan was that we just assign the task and he would see the notification thingy so that we wouldn’t have to bug him for an answer. Developers could move on for the time being and the Product Manager could work un-interrupted until he has the time to get to the task. Efficiency is at hand!
Except it didn’t work that way. The developers dutifully created the tasks, but after a while it became clear that our Product Manager wasn’t seeing the notification. After a bit of digging, we figured out that each user has to subscribe to the notifications that they want to receive. So if you want to know that someone has assigned you a task, then you have to create the appropriate subscription. Bah!
Their subscription / notification system is pretty slick and very configurable. But if fails in one simple aspect: It makes me think about it before I can effectively use the software. I just expect that when a task is assigned to me that I would receive a notification. I would expect that to be the default behavior. I do not expect that I will have to go figure out that I have to create some subscription thing for it.
Frequently developers get overly excited about how configurable and customizable their creations are. They brag about the endless configurations and options. How a user can make it do whatever they want. But they forget that most users really don’t care and just want the product to work out of the box without having to think too hard about it.
Creating a culture of learning September 3, 2008
Posted by Mark Hoffman in Business Stuff.add a comment
Our brains have a virtually unlimited capacity for learning. Which is a good thing for those of us that write software for a living. There is always a new technology to explore; a new language to learn; a new idea to understand. We are constantly learning something new.
Or at least we should be. A software company is only as good as its developers. In the long run it really doesn’t matter how good the marketing department is or how effective the sales department is if the people writing the software can’t build quality, maintainable code. And developers are only as good as what they’ve learned. The pace of advancement in our industry is staggering. It can be overwhelming to just keep up.
The cost of not learning
A developer that isn’t learning is a developer that isn’t improving. Unless you are fortunate enough to be omniscient in all things software related then there are things that you don’t know that would improve you as a developer. That lack of knowledge or skill represents a lost opportunity to build better software. Or at least do it faster. Not to mention lost career opportunities.
Here at AutoRevo, I wrote the vast majority of the software for the first few years. And most of it is..um..less than ideal when I view through it the lens of what I know today. (And if you don’t look at your own code written 3-4 years ago with the same feeling then I would suggest that you probably aren’t learning much!) Had we not learned better ways of writing software and learned new skills, then we would not be able to compete today. We’d be stuck maintaining a mountain of ugly legacy code. But that isn’t the case. We’re able to spend the vast majority of our time adding new features and functionality because we’ve all learned better ways of building software.
A culture of learning
Since learning is so important, you can’t leave it to chance. We have to take steps to ensure that we create a culture of learning. Here are some things that we are doing at AutoRevo to promote learning:
A book, books, books – When you consider the salary of a skilled developer, buying them a book has an obscenely high ROI if it improves their skills. If our developers want a book, then I buy it. It’s just that simple.
Lunch and Learn – Although it has a cheesy name and sounds like something a smartly dressed MBA would come up with, it is something that we’re going to start this Friday. I’ll buy the pizza and soft drinks and we’ll crowd into a conference room with an overhead projector and one of us will present on a particular topic. As I mentioned before, we’re going to be moving to NHibernate so there will definitely be some calories consumed learning about that. I’ve been anxious to dive into the MVC Framework, so I’ll spend some time playing around with it and then showing the rest of the team what I’ve learned. Hopefully, the rest of the team will be interested in presenting on a few topics. Or they will just have to listen to me drone on.
Quiet Time – Developers should be given time to learn. I could write pages on this topic alone, but suffice to say that a company should be providing opportunities for developers to learn. Yes, a developer should be spending their own time learning new things, but those new skills are valuable to an employer as well and the employer should make an investment in those developers by giving them time to learn. I’ve told all of the developers here to take 30 minutes a day of company time to read, learn, play with a new technology, etc. Ideally, they will spend at least that much time on their own doing the same. How much can you learn in an hour a day?
Developers have a responsibility too. Here are some things that developers can do:
Always be reading – The internet is great for learning, but books still have their place. Make time every day to read from a book. I’m currently reading “Agile Principles, Patterns and Practices in C#” by Robert Martin. Next up is Martin Fowler’s book on refactoring. Get a list of books and methodically work your way through them.
Set goals – What technologies and skills do you want to learn? Make a list and devote some time each week to learn about them. For me, I’m getting my head around the MVC Framework for ASP.NET. Then it’s on to F# and I’d like to see what’s up with DSLs. But I have to schedule the time to learn them. There’s always something pressing; always something else to do. That’s why I have to set goals and make them a priority.
Teach – If you really want to learn something, then teach it. Write a blog post or give a presentation to your co-workers. The act of organizing your thoughts about a topic does amazing things to your comprehension of that topic. When I worked as a consultant, I had ample opportunities to teach or present on various subjects. My fear of cognitive shame forced me to learn the topic much deeper than I would have if I were just perusing it for my own edification.
Whether you are an employer or an employee, you need to promote learning. It’s key to building better software and better software companies. Take the time, make the investment and reap the rewards.
Hiring an Attitude August 31, 2008
Posted by Mark Hoffman in Business Stuff.1 comment so far
It’s not easy to find good developers these days. The economy might be sluggish, but the unemployment rates for software developers is less than 2%. Compare that to an overall unemployment rate of nearly 5% and it’s easy to see that demand for developers is quite high.
Which makes turning away applicants all the more harder. But that is exactly what we’ve been doing lately in our quest to find additional developers. One of the reasons for passing on candidates is a lack of passion.
There are three things that I look for in a candidate during a phone screen or interview:
- Aptitude
- Skills
- Attitude
Aptitude is their basic ability to grok the concepts involved in developing software. Do logic, data structures and flow come natural to them? Do they just “get it”? Some people are just made for software development. Other people are not. It’s aptitude and it really can’t be taught.
Skills is the stuff that they know. How well does the candidate know object oriented design? C#? SQL Server? This is the stuff that definitely can be taught if they have an aptitude for it.
Attitude is harder to define. It’s partially enthusiasm and passion. Ever talk to a person who had such a contagious passion about something? Their love of the topic made you care about it, how ever briefly. It’s partially their desire to keep learning, to keep improving themself. It’s a commitment to their profession. It’s passion.
A primary reason that we pass on candidates is a lack of skill. However, that lack of skill is frequently just a symptom of a lack of passion. I’ve screened many candidates and asked them to name something that they learned recently that was important or meaningful. The phone just goes dead for a moment or two and they stammer out something trivial, but it’s clear that they really haven’t bothered learning anything in quite some time.
One of my favorite questions is to ask a candidate to name some blogs that they read or tell me a person in our industry that they admire. Usually the answer is something along the lines of “Um…I read..um..MSDN sometimes.” And the number one answer for a person that they admire in our industry? Bill Gates. Of course, the only reason that Bill gets a mention is because they don’t know of anyone else in our industry. (Number two answer is some form of “that guy at Oracle.” A handful actually know his name as Larry Ellison.)
Someone who has a passion for software development can readily tell me something that they have learned recently. They can easily rattle off a handful of blogs or books that they read. And they won’t hesitate to tell me someone that they admire in our industry and why; someone who’s name isn’t a household word. They love developing software, they love to learn new things and they make an investment in themselves to keep current. And it shows. Passion.
Minimizing hiring mistakes is of utmost importance in building a great software company. One of the ways that we do this is to only hire people that demonstrate a passion for software development. What are some things that you do?
Comment Perjury January 29, 2009
Posted by Mark Hoffman in Tech Stuff.Tags: Comments, Refactoring
add a comment
Recently, I was re-factoring some code with our lead developer and we were looking into how a particular method worked. My first step was to read the comments I had oh-so-carefully placed in there years before when I originally wrote the code. Armed with the knowledge I left there years before, we set out to add some new functionality.
How many of you already know how this is going to end? Well, for those they don’t already know, it didn’t end well. The code behaved nothing like what the comments said. Over the years, the code had changed. But the comments had not. So I ended up wasting time trying to unlearn my preconceived notions about how the code worked.
Our lead developer, Sean Scally, is not a proponent of comments and has been on a mission for years to curb the practice of “undocumentation”. He feels that the code itself should be clear enough for the developer to understand what the code is doing. If it isn’t clear, then refactor it until it is. After we got turned the wrong way because of my out of date comments, he smugly joked about my “comment perjury”. But he was right. My comments were lying to us. They were well intentioned when they were written, but most developers, myself included, rarely go back and update the code comments.
So now, every time I feel the urge to drop some comments to explain what the code is doing, I take a look to see what I can do to make the code a bit clearer. One of the best things I’ve found is to use the Extract Method to pull a code fragment into its own method, where the name readily explains what the code fragment is doing. Unit tests are another way to document your code without comments. In our business, the business rules can be fairly complex and change frequently. Trying to write comments that explain this logic is fraught with peril. (As I’ve learned) It’s much safer to have unit tests that readily demonstrate what the business rules are. As the rules change, you update your tests then update your code. No need to remember to update that big block of comments that nobody bothered to read anyway. And you get the added benefit of having your code under test coverage.
As in all things in life, moderation is key. I still hold that a properly placed comment can make a world of difference in understanding the code. But they should be used carefully and judiciously and only after other ways of documenting the code have been exhausted.