Blog Battle – SEP is currently having a blog battle between some of the employees. This week’s challenge is the title – All I Want for Christmas.

All I want for Christmas is essential complexity.

As I move from project to project, the interesting part is not the code. I care about software architecture for the same reason Shaker carpenters worried about mortis and tenon joints. They help make the table look and act like a surface for making and eating nourishing meals. That’s it.

Shaker designs are simple and distilled from years of learning and sharing. But they did not ornament their work. Those fancy overlaps on the oval shaker boxes? They were the back. Not meant to be seen. They shunned inlay and other ornamentation.

There are two parts to software that make it hard. There is the actual work we are tying to do, the complexity that comes from health insurance regulations or keeping aircraft serviced. Then there is the stuff we do to ourselves. By being to clever, by trying to do more than we should. This second complexity is incidental to the work at hand.

So here is want I want. I want to have a program that looks like the business rules. It screams, “THIS IS MY UTILITY! THIS IS MY REASON FOR BEING!”

I want to be able to write this code. To craft this software. To make the hard parts of the user interface and data access code disappear unnoticed behind an app that just works, and code that is only on service of simplifying that work as sparingly as possible.

Blog Battle – SEP is currently having a blog battle between some of the employees. This week’s challenge is the title – Motion != Progress.

When given this topic, a lot of people are going to talk about how to ensure you’re making progress this week. I’m sure of it. At SEP we are deeply culturally committed to Agile and Lean philosophies. We like making a difference and writing software that matters. It doesn’t matter until someone uses it.

How to look busy and not do a damn thing

It is sometimes useful to look at the other side of a topic. So let us explore the fine art of sabotage and see if we can identify patterns of behavior that, even when not intentionally malicious, can have a huge negative impact on a project’s ability to close in on “shipping.” For each of these, there are legitimate reasons, which is what makes them effective. In the real world, don’t accuse people of sabotage.

This is based on a riff I did as a lighting talk because of an old OSS field guide used by the French Resistance.

• Rules rule
  Make sure everyone follows all the rules all the time. If you work in a regulated industry, apply the most rigorous rules to projects that don’t need it. Add more cross and double checks. Constantly audit the status of those rules and stop all work until everyone is in compliance.
• Make your voice heard
  If someone manages to finish their action items for a meeting, talk about them in detail. If someone is assigned an action item, that’s just a chance for you to talk some more. As for everything else, try restating it in your own words. If you are invited to a meeting, you should spend 1/2 of it talking.
• Everyone matters
  Make sure others also speak. Especially if it seems like the meeting has wound down or met consensus. Pass the talking stick! Make them restate the problem in their own words. Start bringing in people from other groups. Reschedule if others aren’t going to make some meetings.
• Details matter
  Never leave room for interpretation. Why let implemented exercise judgment? More importantly, if you optimize locally and create contradictory rules, it only means more meetings to sort it all out later.
• Documentation is key
  Instead of a quick memo stating an expected impact, require a formal report with facts. Make them prove that the bad is actually bad. Time spent documenting is time spent. It isn’t good enough to be comprehensive, it must be edited then change the decisions to make sure the document is once again in need of a drastic rewrite.
• No business like old business
  Since we are constantly changing our minds, we should reopen old decisions to make sure they are still relevant. Even stuff discussed last meeting. Bonus points for changing core functionality that’s been in place for months.
• Mitigate all risks
  More time spent proving a risk or reducing a risk is more time spent. If it might annoy one user, it must be pursued. One person’s choice is another person’s risk.
• Respect the hierarchy
  No project exists in a vacuum. Make sure you fit well with other teams and integrate with them. Spend time making sure they mesh well with you. Use their techniques even if they aren’t a fit for your team.
• Don’t use it until it is done
  I cannot provide feedback until I can judge the whole thing. In addition, once you find a single problem you should stop review until that issue is fixed. You can’t provide useful feedback when you know it is broken. Don’t provide thorough feedback on issues. Call a meeting if they want more detail. Make sure the room is packed.
• Redesign
  Sweeping architecture changes are a great way to call a bunch of people in to a room, make them write a bunch of code, and risk new issues. Try to avoid actually improving the architecture. If they can develop faster and easier once you’re done, you did it wrong.
• Ask
  Is there a choice to be made? Make someone else responsible for it. Especially if they are out of the office and will take time to respond. Call a meeting if they are in town.
• Don’t ask
  Assume. An assumption, especially a seemingly minor one that can go undetected for a while, can ripple out a bunch of issues, meetings, and rework.
• When in doubt, call a meeting
  If everyone is busy, it can always wait till next week. Let meetings ramble.
• Spread responsibility
  The perfect model for decision making is the UN Security council. Make 5 people responsible and give total veto power to three of them. It takes a while to build consensus and differing opinions leave all kinds of interpretation open for conflict.
• Work on several projects at once
  No only does this make it harder for them to schedule you in a meeting, but you now have twice as much work to not be doing!
• New Priorities
  It takes time for people to ramp up and become familiar with a new project or reorient to an old one. By constantly shifting team members from one project to another, you can keep driving the starved project behind schedule requiring a shift of a number of people off of a team that finally started being effective and on to one requiring ramp up time.

But seriously, don’t

Don’t assume sabotage. I’ve seen all of these in different projects at different times. Fortunately, no one was doing any of these with malicious intent. Usually, choices are made for the people involved on a project from several organizational levels beyond their control. It is very difficult to do your best when those doing the work aren’t in charge of the methodology.

In addition, a lot of these are perfectly valid in the right context. And you have to seek understanding of the whole story to get the real context.

Blog Battle – SEP is currently having a blog battle between some of the employees. This weeks challenge is the title – The Optimistic Programmer.

When I was a young college aged programmer visiting my Dad at work for a former employer. I got an object lesson in optimism.

He had managed to steal a couple of developers from the IT department. Their job was to work with the scheduling staff to make sure all the planes can move all the scheduled flights with pilots that are legally allowed to fly at that time carrying catering selected by the share owners. There are many combinations and the chance to save a lot of money of you pick the right schedule. They eventually wrote a couple of programs.

We could have gone on about Operations Research and the scheduling algorithm, but we didn’t. What we did talk about was the flight grid. It was a huge screen full of planes, times, events, and notes. This was way back in the olden times before the Y2Ks. He said it was snappy. In fact it did scroll quickly with no noticeable stutter.

Then came the kicker. “There were a couple ways to do this. One was inefficient and the other was really hard. Turns out, the inefficient way is quick enough.”

Then I heard about a Knuth quote. “Premature Optimization is the root of all evil (or at least most of it) in programming.”

You can’t tell if it is worth the effort unless you can measure it. And sometimes, good enough is good enough.

Blog Battle – SEP is currently having a blog battle between some of the employees. This weeks challenge is the title – I Don’t Have Time.

I have, on occasion, been asked where I find the time for playing with all of these cool languages and frameworks. Or presenting. Or teaching an internal class.

Funny how no one ever says, “Where do you find the time to watch America’s Got Talent?”

When someone says the don’t have the time they are actually saying, “That’s not important to me.”

About a year ago, I started studying for a .NET certification upgrade. Since SEP is a Microsoft Gold Partner, they made it worth my while to maintain my certification. It wasn’t easy. I spent at least a couple hours on most nights studying for about three months. The opportunity cost was I could have spent that time with my wife. I would have spent that time playing with frameworks, software, etc, but I would have done it while watching TV with her as she wrote lesson plans, graded papers, or made crafts. Or helping run the house. Fortunately, she had buy-in on this endeavor since that much time impacted her life as well.

I don’t go fishing. I don’t watch the local sports team with friends. Software is my hobby. I used to play role-playing games with my coworkers. I used to draw a webcomic. While I still enjoy those things and occasionally still draw and game, I have other things I would rather be doing most of the time.

When I explained this, I was told when I have kids I’ll understand that doesn’t fly.

Surprise! My wife and I now have an infant daughter. Here’s the deal as I see it now.

It is still a matter of setting your priorities. Figure out what those are and align your life to them.

Shortly after we returned to work we realized that just about all we were doing was either cleaning the house or taking care of our daughter. Or in her case prepping her class of first graders. So we’ve made a simple deal. We need to find time for one another to do the things that make us who we are. She has blocked out time to bake and make cards. I have found time to attend a user group, read, draw, and even blog on occasion. We shop together and find time to eat out. These take time. I could take Sophie grocery shopping, leaving my wife time to lounge on the patio with coffee and a book, But it’s time we are willing to spend because it is time spent together. And she hates coffee.

The other thing about our doing those things they are either scheduled or can be done in snatches.

Some things are still not happening. I don’t get much of a chance to play music since I’d rather spend my time elsewhere. I don’t attend Code and Coffee because I’m driving Sophie at that time in the morning. But I’m not whining about those losses. I have chosen. I have edited down my life to handle a bigger priority. I love the time I spend with my little girl, and I’d rather spend time with her than many other things I also enjoy.

Let me walk through some time sucks and cases why you might choose to spend that time.

I work 60 hours a week or have a long commute. Some employers are the only way to get health benefits for children and spouses with preexisting conditions. To make enough to raise a child with a stay at home parent, you may have to trade a ‘fun job’ for a better paying job at the expense that you yourself spend with your children. Self employment sometimes trades the flexibility and autonomy for time.

My kids have so many activities. You enjoy spending time helping your kids find friends and activities they are passionate about. You may even enjoy participating along side.

I have to fix up my fixer-upper house. You traded home cost for your time. You enjoy rebuilding the house and making it your own.

I have meetings with some organization. You find participation with this group fulfilling. Or you see networking opportunities that are important.

There is no secret to finding time. You can’t fit 25 hours in to a day. You sleep less or do less. I would avoid sleeping less. I have an infant daughter and I know where that leads.

So, let me challenge you. Next time you find yourself saying, “I don’t have time.” Ask yourself if it’s because life happens to you, leaving you with no choices. Or admit that you have other priorities and it’s just not as important. Then find peace with that.

This week’s blog battle has begun!

We, those of us who fancy ourselves serious developers, like to disparage the enterprise developer who specializes in a class of application called Forms Over Data. The Business needs to save some data, so they have the DBA lay out a table. The developer then points their IDE at the table and drags input element on to the form and bind columns to text boxes and BAM!, they are done. System.DraggyDroppy. It doesn’t scale to Real Development. Not when I have a rich set of domain objects.

When I started full-on professional development, the summer before my senior year, I wrote web pages. Each page was a thin veneer over the database. Until I had to add more logic and added a bunch of ifs and elses in to the page. The fact remains, the data I was manipulating was pretty anemic. I’ll call this Pages Over Data. The difference is I have an implicit Fat Controller in my CGI script that the forms over data didn’t.

As I’ve done more desktop and mobile development, I’m starting to see that I’ve just done the same damn thing. Over and Over. It’s how I’ve always done it.

Recently, I have heard several people talk about software architecture. James Coplein has been promoting DCI. At work a few of us have been thinking about rereading Eric Evan’s Domain Driven Design. Despite none of these texts exploring a new idea, despite none of these ideas being things I heartily agree with, despite having evangelized and touted these ideas; I’m not very good at it. I keep finding myself doing pages over data.

What am I seeing? In one case, we had to stand up a bunch of screens for a user study so we’ve stuck a bunch of logic in Android Activity classes. While we’ve been refactoring this out, the odds are good we will always have some of that sticking around. In another case, we had a “business layer” that another team managed and UI designed a screen at a time. Our ViewModels had a lot of logic that we decided didn’t belong in the BL as that was a representation of only the data to be saved in the file and enough logic to ensure consistency and validity and undoing edits.

I can’t put my finger on WHY I don’t like these things, but I don’t. I’m on a quest to overcome the architectural momentum I’ve developed. Here’s what I’m going to do about it. I’m reading a bunch of architecture stuff. Reading along is only so good, so I’m writing a pet project a few times to explore each architectural style I’m working with. Hopefully, this will give me a better understanding of what I’m feeling and how well these styles work for me. So the next time I’m done with a project I don’t look back and say, “it’s just Pages over Data.”

This weeks Blog Battle was a song title. Just to make a point, here’s a video!

When I has a young software engineer, I was a Perl hacker. I could do amazing things because I spent so much time learning the ins and outs of the language. I blame, in part, Dave Mott for showing me what was possible. But also people like Damian Conway for things like Lingua::Romana::Perligata, a library that allowed you to write code with Latin grammar rules, because they showed me how to make the world a slightly crazy place with their code. And to enjoy code for its own sake.

I used Perl, not only in direct project work, but to slice and manipulate any data I had to deal with. I didn’t have a machine without it installed. At least is was not long until it was installed. When I did use it, odds were I would write code that others would call messy and dangerous. Calling methods that don’t exist. Rewriting the symbol table for just a little while. Writing code that changes file without opening them. It was there I learned that it can be easy to solve problems with a dash of black magic.

I started learning Ruby because all the cool kids were doing it. I’d heard about Rails, and I had seen it mentioned in both the Pragmatic Programmer and Extreme Programming Adventures in C#. I stayed for a while because of things like Rake, rSpec, and people like Why the Lucky Stiff, who, like Damian Conway, made the world a little stranger and a little nicer.

I explored “block” and finally understood what all that crap I was doing in Perl was now that “metaprogramming” had a name. Wrote my first internal DSL because I hated the language I was targeting. I learned that code needs to be ‘ergonomic’ and easy to understand. I still used magic, but I kept it in a corner of the code.

The weapons I’ve been looking at recently are mot because they are inherently useful to me, but because they make me think differently. Haskell, Erlang, Clojure, and F# are not things I can as immediately push in to a project, but they teach me about the form and movement of their usage. You see, C# is no longer as pure an OO language as version one was. You can make an argument that it never was pure, but it is taking so much more from other language paradigms because of people like Erik Meijer. And they have helped me write very different C# that is more expressive and succinct than anything I would have been able four years ago.

But what serves me best? In each case, I try to understand the language for what it is, not for what is is expected to be. Each feature should be approached with the beginners mind and explored from several angles. Each is different and can be used in a variety of ways. A master swordsman can strike with any part of the sword.

As I get older I realize my weapon of choice is not any specific language. I have favorites and some I understand better than others. Those are matters of fashion and taste. A master swordsman understand the sword so well, he can turn any object in his hand in to a weapon.

That’s my weapon of choice; what ever is close at hand.

I’m not sure I’m sure where to go with with this week’s blog battle, Engineering Over/Under. But, a deal is a deal, and I’m still posting more than Moseng! By the way, this post has no answers, just some ravings.

I participated in the Science Olympiad when I was in high school. I did well in two competitions, orienteering and clock building. The other task I had but didn’t do so well in was bridge/tower building. I’m sure my bridge would have been the most efficient, but for safety reasons there was a limit to how much weight they would put on my bridge. The bridge was over engineered. In order to win, you need the most efficient bridge that will fail. If it stands, there were inefficiencies in the system.

There isn’t much to that story that has to do with software. Over engineering is about costing too much for the job at hand.

The truth is what we call over engineering in software is about picking the wrong things to build. It isn’t over engineering to put a ferris wheel on a bridge, it’s just wrong. But to build N-tier web services when all you need it to catch responses from an employee survey? We call that over engineering for some reason. No one complains if you make it too fast. But these additions to our software take more time and money and often make your software worse.

So what do we do about this? Focus on what you really need to build. Try not to get caught up with arbitrary requirements about how this needs to be web-scale or have zero latency. Now, the trick is balance. These are valid concerns that may be important, so you can’t paint yourself in to a corner where you can’t easily address them in the future.

Wait, what? Not make it right the first time? When architecting a real building, it is possible to design a building with rooms and features so specific to a certain layout that you can only use those spaces in specific ways. The obvious examples are bathrooms and kitchens (I’ve been thinking about a remodel for a few years), but auditoriums are also problems. The real treasure in building architecture is making flexible spaces that can be used for many purposes and occasions. Have you ever really looked at a great museum’s architecture? The galleries can usually be reconfigured in very short order to accommodate new collections or events.

In software, we like to try to keep our business logic free of our persistence or display technologies, just like rows of theater seats and a stage make it hard to repurpose a room. Some times the Smart Forms pattern is actually the answer. And sometimes it may be okay to do a little work in the UI thread.

Once again the gauntlet has been thrown. I have taken up arms and the Sep blog battle has been joined. Because I’m a better person than you.

That is a common refrain around my office, “because I’m a better person that you.” Okay, I’ll fess up. It is actually just me and it’s not that often. It is also all a lie. I’m not better. I am actually a recovering fraud hiding behind my insecurity.

There is an a branch of theology that essentially states nothing you do matters, salvation comes to an elect few through no action of their own. This was practiced by the lay members of the early American churches as, “If you got away with it then God loves you. If your crop die or you lose your job you are evil.” This is less innocuously practiced today with phrases like, “I can’t draw. I’m not talented.” Or, worse, “I don’t care, I live a charmed life and can do what ever I want.” It is, in my mind, a cop-out. It means free-will is suborned to some other will. It means my choices are pointless and I may as well just sit on the couch and count flowers on the wall.

When this hit me professionally I had just had a contentious run with a project lead and felt exiled when I moved to my next project. I looked around at the situation and made a discovery, several of the people I graduated with had accelerated their career and I had stalled mine. Some of this was an accident of our exposure, but some what about realizing what’s important. I realized that I was focusing in the wrong things. I changed my focus and got back on track. I now know I was the perfect fit for that exile and I learned awesome perspectives there. I would do it again for the first time.

I can’t promise you that you will be the best, but I can promise you that you can be your best and do things you never thought possible. When studying the luminaries of our industry, most of them have worked hard to be able to do the things that have changed our world, but I’m not sure they are that different from us. Anyone can write a database engine. Anyone can write a programming language. Now, making it good requires effort. And achieving awesome means you stop telling yourself you can’t and never will. At a more personal level I know what keeps me from being a better artist. I don’t draw enough.

So the next time someone notices the fruit roll up in your lunch and expresses envy, let them know the only reason you have it and not them is that you did the work of putting it there in the first place. You know, “because I’m a better person than you.”

So, why do I strive to get better? The choices I make matter and I use those choices to make a better relationship, a better home, a better career, have better fun, and build a better me. I get better so that one day I can say, without a trace of irony, “Because I’m a better person than I was yesterday.”