Improvement

I would have written a shorter letter but didn’t have time.

Improvement, Techniques

I received an email from a coworker. The email was terse and wordy at the same time. I’m not sure what the author wants from me. I think he wants me to take some action. Perhaps he wants me to help advocate for the use of the tool he is talking about. Perhaps he wants me to tell him what his next steps should be. It is a rambling email that never gets to the point.

I read my fair share of emails like this. I have written them as well. And not just email. Much of what I read could get to the point much faster. I am trying to get better at writing by writing more. I am using an excellent tool, Hemingway Editor, that helps a lot with keeping my writing succinct.

The biggest problem I have in my writing is long rambling sentences. I often write sentences that should have been a paragraph. These are never as clear and understandable as they sounded in my head. That alone is reason enough to use Hemingway but it has other features that help reduce complexity. If you spend any amount of time writing, you should give it a try.

Advertisement

Optimize for Maintenance

Improvement

When you are building software, you can optimize for one of two things. You can reduce the time it takes to create or you can reduce the amount of effort you will put into maintenance. Old school RAD tools (and much of Microsoft’s demo-ware) optimize for quick construction. Tools like ORMs (especially Entity Framework) and Rails also make this choice. They all allow you to build solutions quick, and there is nothing wrong with that, if that is what you need.

Most software will live for many years, so you will spend much more time fixing it and adding features. This is where the whole RAD strategy falls apart. Most of the tooling that allows you to build fast (look Ma – no code!) does not hold up well to attempts to maintain it. It allows hidden complexity to creep in while you work around the tooling to fix a bug or add a feature. Before you know it the whole stack of software is hard to debug or add to so nobody wants to do it.

This is why developers fight against having to do maintenance – because they have made it hard on themselves. Developers would like their jobs better if they built for maintenance instead of trying to meet aggressive deadlines.

My thoughts on what it means to be an architect

Architecture, Improvement, Techniques

An architect is like an Army Ranger, or an Old West scout. Their job is to go ahead of the main force to determine the best paths and clear obstacles when appropriate. This means it is up to them to figure out what technologies and architecture patterns to use. It is their job to find what the risky parts of the application or system will be and prototype them enough to remove the risks. If these prototypes are meant to become part of the production software (and let’s be honest, they always become part of the production software) they have to be built to the same standards as production code, which means good automated tests (unit, functional, and integration, as appropriate). They need to be prepared to discover that the approach they wanted to take is not the correct approach and abandon it before a lot of time and effort is spent trying to make the wrong tools or technologies work. Sometimes the seemingly obvious path is not the best path. You may have to attack a problem from an unusual direction to get to the best solution.

In order to do this, architects need to be able to see the big picture yet still write good code quickly. Good code is code that is easily understood and maintained, which means code with tests and low complexity and coupling. Not every developer can see the big picture – it is easy for us to get lost in the details or try to create the perfect solution instead of just doing enough to satisfy the requirement with solid code. This is not a bad thing if it can be kept under control, and the person qualified to keep it under control is an architect. A manger will want the developer to stop at satisfying the requirement.

Architects need to be concerned about the -ilities of a system. They need to keep an eye on performance – will the system be able to handle the expected number of peak users while still being responsive? Will it handle user load while background processes are under heavy load as well? Can it handle securing it’s data from malicious users and outside attack? The person qualified to make sure good technologies and development techniques are used to produce the system may not be qualified to define performance tests or security. This is why you often need a team of architects each specializing in one or more areas. Of course, this does not absolve an architect from knowing anything about these other concerns – an architect should know enough about these thing to call bullshit on bad ideas. But you need to have people with deep experience and knowledge in these important areas, and it is extremely unlikely that one person will be able to do the job. This is why you need an architecture team for any project of significant size.

Architects should not be treated in any special way. They will have knowledge that other people do not, but they should not horde this knowledge. They need to accept that other people may have good ideas as well and be ready to hear them out and employ these ideas when possible. In order to make this possible, they need to be approachable and respectful of these opinions and ideas. They should document decisions with the ideas considered and the reasons why they were not used as well as a compelling story for the idea that is being used. This provides a level of transparency and over time will give others an understanding of what values the organization holds when considering technologies and architectures.

Done properly, being an architect is still a very hands on job. You have to maintain your coding skills and keep in contact with other developers, or else you will stagnate and become of little value to your organization. You need to have solid teamwork skills because modern software requires lots of experts to get to a solidly built, long-lived result. The days when architects could hide in an ivory tower are completely gone, if they ever really were here.

Thinking About Verbs

Architecture, Distributed Systems, General Coding, Improvement, Techniques

In my last post, I said you should model verbs, not nouns. I probably exaggerated a bit (I tend to do that) – you shouldn’t completely forget about the nouns. Your verbs wouldn’t have much to do without them. Instead, you should be focused on the verbs and the details of the interactions, not the details of the nouns and adjectives (those will take care of themselves).

Your users want to use your application to get work done. As a I said, gone are the days of simple data entry applications (well, not completely, but certainly anyone building new products isn’t working on solving data entry problems). They want to perform tasks using your application – ordering a book is a task, not a data entry activity. Dispensing a medication, verifying the number of 2x4s in stock, checking a book out of a library – tasks, all.

This is not a new concept. Microsoft published an article about Inductive User Interfaces back in February, 2001 (Inductive was their term for task-based). Tasks have been the focus of various writings about Domain Driven Design, CQRS, and Event Sourcing. Another similar approach is the DCI Architecture, which is a little more formal but also acknowledges the importance of the verbs (or interactions, as they are called).

Which of these approaches, architectures, or techniques you use isn’t overly important. What is important is that you consider the verbs, the events, and the interactions. My last post came from a meeting we had at my company talking about how best to handle data transfer objects. We came to the realization that it was better to have a different DTO for every context, even if they contained the same properties, because as time went on, each of these objects would have their own reasons to change.

This led to trying to determine how best to name these things. How do you differentiate between 6 different OrderDTO classes? The answer is, you don’t – the order isn’t the important part. You focus on what the consumer of the DTO is trying to achieve and use that for the name. This is of course a fairly contrived starting point for a discussion of verbs – I still am starting from nouns (orders are nouns). But it led to further discussion about the way we needed to think about things – in terms of the interactions. If we had started there, we would have had an easier time of things. Fortunately the system under discussion still has a ways to go and we have plenty of time to make use of the lesson.

Special thanks to Matt Otto, who reminded me of DCI Architecture, as well as linked me to this very amusing article that basically makes the same points, although much better.

Model the Verbs, Not the Nouns

Architecture, Distributed Systems, General Coding, Improvement, Techniques

For most of my career, the “best practice” has been to build applications from the data up. You model the database and then everything will be happy. Its just the way you do it. There is no other way.

So what’s the problem? You end up building applications around what data you need to display and what data you will update. So you show the user all of the data they might need, because you don’t know what they need. You ask for all sorts of data, because you might need it for some scenario. You build screens that they can use to enter any changes that might occur with this data, no matter why those changes are required.

The problem with this approach is there is no “why?”. Why are you showing the user this data? Why are they updating it? What is it that they are really trying to do? You end up with a lot of very obtuse code that is hard to follow, because its only concern is pushing data to the screen from the database, or vice versa. It flows through a lot of logic that you might need in case of various scenarios, but its impossible to know what rules apply to what scenarios, because there is nothing about your code to imply intent.

Back when I started in this field, I was building applications to allow users to put paper forms into databases. There really wasn’t much more logic than that. I was not alone in this – its what most applications did back in the early 90’s. We were trying to build the paperless office, after all.

We can do so much more now. In fact, our users expect it. In order to do so, though, we need to think about the behavior that is expected. What is the user trying to accomplish? Why? What is the intent?

If we examined the behavior, the verbs of the system, instead of just the data (the nouns), we’d have a better understanding of what it was we are trying to build. Our code would be more obvious. The user’s intent would become clear. And then we could build the system the users actually want to use, the one that helps them get their work done in a more efficient fashion. The one that they don’t constantly complain about (OK, that might be a stretch…).

Model behavior by thinking about the verbs. The nouns will follow.