Good Software Architects

Do you have to be a good software developer to be a good software architect?

This is an interesting question that came up in a random conversation with a friend. He was of the opinion that a person can be great at high level design, but be bad at actually programming. He claimed that the two activities are far enough apart that someone could be good at one and poor at the other. I'm not sure that I agree.

Part of high level design is thinking about how the implementation will actually work. A lot of the time, something looks great on paper, but it's a major pain to implement. Sometimes it's not even worth the effort to implement. A good architect should be able to balance these factors, and being a good programmer helps identify these potentially troublesome design choices.

Further, to be a good software designer, you need to a lot of experience working with growing applications. You need to know how each design decision effects the project as a whole, as well as the developers working on the project. I think the best way to get this experience is from working as a developer. That way, you get to see the good (and bad) ramifications of design decisions first hand.

Being a good developer also gives the architect a better view of any software project. They know how every detail might work, regardless of whether it's a high level design choice, or a how that design choice might be implemented. This gives the architect a more complete view of the project, and allows them to make a more informed decision.

I am very curious about what you guys think. Comment to let me know what "camp" you're in and why. I'd love to hear everyone's take on this.

UI Driven Architecture

At few days ago at work, my coworkers and I realized how powerful UI driven architecture can be. We had back end code (partially) written, but once we started designing the UI, we discovered that a lot of it had to be changed. That cost us a lot of time. It's really hard to design a system unless you know precisely how it will be used. Designing the back end first can create all sorts of problems when moving on to the UI work. Sometimes you find that the back end doesn't interact with the UI in a clean way. Instead, you should design the UI first (even if it's just a prototype), and let that inform the back end development. This is essentially an argument for top-down, user interface driven design. This seems to be especially important if your UI has a lot of workflow based interaction. Thinking about validation can also save a lot of time. You have to make sure your API can handle whatever the UI wants to do in a natural way. It's certainly an interesting approach to designing software, and I think I'll be doing it in the future.

In other news, I am really excited for ARTS 304. There is going to be a lot of learning going on in the next few weeks. I don't think anyone in our team has ever done mobile development before. This should be fun. :)

I also just finished my first sprint at work. Exciting stuff! I am really enjoying my time at Karos. The software we're working on is super cool, and the people are hilarious. Good times to be had all around.

Architecture Lessons at 3AM

I learned a nice architecture lesson last night: Think about error handling early. The wrong time to think about it is at 3AM after most of your functionality is built in.

Originally, our architecture relied on returning null on failure. The levels above would check for this and handle it appropriately. There are a few problems with this. The problem that impeded us the most is that we were unable to differentiate between various kinds of failures for some method. In hindsight, this isn't a very clean way to handle error handling in general.

The first solution we tried involved an external error handling class. Our model (and data access code) would set flags in this static error handling class to indicate what went wrong. This meant that every time someone wanted to call on the model to do something, they would have to remember to check the error handling class to see if anything went wrong. This created a coupling between this error handling class and our models. If you forget to check that error flag, your code would fail silently or cause unexpected behavior. We eventually scrapped this idea in favor of exceptions.

Exception were better because any failure would force the programmers to deal with it immediately. If they forgot to catch the exception, the program would crash right away, and with a very clear reason (like SQLException). You could not simply ignore the error and continue running in ignorance like with the other static error handling technique.

After we decided on exceptions, we started talking about whether we wanted checked or unchecked exceptions. More fun debating there. All this happened after 2AM. I am always hesitant to make important design decisions at that hour.

We eventually decided to go with checked exceptions. This means changing almost all of our classes (including all our tests). Granted, the changes are fairly simple and straightforward, but it's still going to cost us some time to re-factor everything. Had we thought about error handling straight away, we could have saved some time.

Moral of the story: Think about error handling during your planning phase!

On an unrelated note, Willis and I got 97 on OS A2. Hell-freaking-Yeah!