Where Did Use Cases Go?

I've always liked use cases as an analysis/design tool. I was even the lead developer on a now defunct use case management tool. What ever happened to them? I never hear any one talking about them anymore. Sad really. They were an important part of the journey to understanding user needs. It made gathering easier as well as grouping functionality together. When done right, domain modeling was a breeze. Sure, you never got all of the use cases before design started, but at least you had a good idea of what the goals of the system are. I'm still shocked when I get on a team and the goals of what the software is to do is not clear.

It seems in the rush for agility that people threw away use cases as well. I don't know why. I think stories are a horrible mechanism for understanding. They are the lazy man's use case. Modeling the main domain objects and a good cut at use cases is crucial before you start coding. It will save countless hours. Now, this might seem un-agile. But, thinking about your problem and trying to get a good grip on it before you start coding IS agile. Writing use cases does not end when you start designing or when you start coding. It's a continual process. Use cases are needed to be not only for the knowledge of the developer, but also so that the client knows exactly what you are building. They are to be done together. And as any experienced developer will tell you, you never know everything about what you're building. Customers and developers need each other. Use cases are proof of that.

Use cases rock.

Omaha Dynamic Language Group

The great talks keep coming and this month we have none other than Matt Secoske talking about Domain Specific Languages (or as you might have read about: DSLs). This looks to be an all out blitz to the senses and one that will be talked about for ages. I think it's safe to assume, you need to get out and see for yourself. Matt will show how dynamic languages are perfect to implement DSLs in. It's at the same place we had last month and should be great. See you all there!

Topic	Domain Specific Languages
Speaker	Matt Secoske
Time	March 6, 7-9pm
Location	UNO's Peter Kiewit Institute (PKI) building 1110 South 67th Street Omaha, NE

Made it home...

I made it home and I was exhausted! But, I did write down some more ideas:

1. Seats in the airport should double as beds. And they should be more comfortable.
2. There should be a stock of pillows for people sleeping in the airport when bad weather hits.
3. Lower volume on the intercom. In fact, get rid of the damn thing. It's annoying and there's only so many times I want to hear about "orange" security level. Place more terminals with good information and have it be up to do date. The biggest problem over the weekend was lack of information. Rumors ran rampant and a terminal with information would have stopped most of it.
4. No leaning back chairs on airplanes. They are simply a BAD DESIGN. They are good for one passenger and bad for another. Either that or make more room on the airplane.
5. Don't lie. If you don't know the answer, tell me. If the answer is unpleasant, then tell me. Imagine my surprise when I was told that my luggage was following me through the cancellations, but in fact, it is still in Memphis.
   

OK, that's all of the extra ideas. I think flying could be so much nicer. Everyone I talked to complained about security, but I think we are stuck with that situation. I know people will probably roll their eyes, but it was good to turn that negative energy into creativeness. It also got me thinking of other things as well. But, more on that later!

Stuck in Memphis

I've been at the Memphis airport all day long trying to get home. The weather has not been nice. Hopefully, tomorrow I'll be able to get somewhere, but I'm thinking it might just be another day of waiting. I spent most of the day waiting in line when flights were canceled and it got me thinking. Instead of complaining about a bad situation, how would I fix it? So, I started to spend my time brainstorming ideas to make canceled flights easier on everyone. Here's my list:

1. Create more than one line. I would divide them up by flexibility of travel plans. I notice a lot of time is spent with just a few passengers. You could use one line to determine what the needs are and then pass them on to more dedicated lines. This would speed things up for everyone on the whole.
2. Updated information on the boards. Most of the problem is that you don't know what's going and there's no confirmation that you're doing the right thing. It's chaos. Some road signs would answer most people's questions (flight delayed - for how long - and yep, it's canceled and with the reason!).
3. Send flight information to your cell phone for each of your flights. If it gets canceled and they automatically rebook, then notify me. If the default is unacceptable, then I'll wait in line. But, give me options. I'm thinking the default would the best for most people and reduce the line size.
4. "Feed" the line. People are generally tired, cranky, and hungry. Pass out refreshments while they wait in long lines. It will keep the natives peaceful.
5. Workout a deal with a local taxi company to pick up the slack to take people to the hotel. I waited an hour tonight just to get to the hotel.
6. Workout a deal with the tourism department to show around town if their flight is canceled. They have time to waste and might want to venture out.
7. Have shuttles from the hotel that take people to malls or Wal-Mart. Why? Because you don't have your luggage and might want a fresh set of clothes.
8. Have private areas in the airport. I would spend money just to have a small place to prop up my feet and take off my shoes. I'm thinking something with walls and a Laz-E-Boy chair.
9. Better food. Airport food is expensive and junky. Sometimes I would give anything for some vegetables and something healthy. How hard can that be?
   

Well, that's all I can think of right now on 2 hours of sleep. I'm sure I'll think of more tomorrow. Good night.

Books on Design

In one of my comments, someone asked me the book that I would recommend from Rebecca Wirfs-Brock. And I thought why not just put some of my favorites into a list? So, here's my list in no particular order, but all of these come highly recommended:

• Designing Object-Oriented Software : THE book on OO design and analysis. This one keeps it simple and is awesome. Mrs. Wirfs-Brock will always be one of my heroes that I aspire to.
• Domain Driven Design: And I'm not saying this because of my involvement with TimeAndMoney. Eric is not a great mentor, but an awesome author. If you want to learn how to write REAL DSLs, this is the book. Learn to talk through your domain. Read this cover to cover. There is not one paragraph not to be savored. I went to the first Smalltalk Solutions just to meet him. Seriously...
• The Design Patterns Smalltalk Companion: This is the book where you learn a lot of the hidden secrets in Smalltalk and that all of the design patterns started there. This is an awesome book and reads better than the original. Buy this even if you don't know Smalltalk. It's that good.
• Structure and Interpretation of Computer Programs: I don't know one person who has read this and not have had the way they look at software be different. Learn to be a magician. This opened a lot of possibilities for me. It made me much more creative in my solutions.
• Prefactoring: A lot of Agile enthusiasts got upset with this book because they didn't read it. This book dares to followers to do what they say: Think about their designs. This is also a great book if you want to learn more about DSLs. All good OO models are DSLs. If you're not doing a language with your models, you are doing something wrong.
• Agile Software Development: Robert Martin hits a home run with this book. This is what people who think Agile is about no design, should read this. Being agile is about thinking. I know a lot of Agilists get that, but I have come across many who think it's all about coding and no thought. This book goes beyond Agile and talks about good ole great design.
• Software Fundamentals: These articles were written before I even knew what a computer was and they are still relevant today as they were then. You'll either walk away from this bewildered at what we keep rediscovering or notice how a lot of stuff that seems new is really rebranded. This book is just an awesome tomb of software experience from one of the early innovators. His views on encapsulation really changed the way I look at design. Awesome book.
• A functional pattern system for object-oriented design: Functional programming for object-oriented programmers. I love functional programming and by studying it. My thoughts on development and design have changed. This book shows that they both can share ideas from each other and become stronger. This is a fantastic book that should get more accolades. It shows what great things can be done if OO and functional programmers put their powers together for good.
• Every single book that Martin Fowler has had his name on or associated with. They all rock. Analysis patterns is really the crowning jewel (again, if you want to do DSLs, learn from the master). But, all of his books are easy to read and will teach you volumes.
  

I could go on all night, but I'll stop here for now. I didn't even get to the books that I love from Gerald Weinberg, Donald Norman, Shlaer-Mellor, and more, but I will make that for another blog entry. Also, I'm a big junkie for all of the pattern series books. Nothing takes my money quicker than a pattern book. They are chock full of ideas on design and clever solutions.