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 – Good Idea, Bad Idea.

Create your own language! I have had great success creating my own language in the past. I already wrote about it in I’m Using the Wrong Language, so ill just sum up. We were writing test files but the scripting language used by the simulator was general purpose but had problems expressing our scenarios and had zero concept of code reuse. So I wrote a language in Ruby to generate the test scripts from a more declarative language.

It was Awesome! Complicated tests became so much easier to develop and review and had fewer bugs. There was, as the kids say, ROI.

Create your own language! I’m currently playing with Writing Scheme in Haskell. I wouldn’t suggest tackling such a large undertaking ask writing your own language for your project. Now you have multiple languages in your project, you have to handle performance issues, there are untold corner cases to be worked out, it currently has no system interactions, and you have no existing community upon which you can draw for help.

It is still awesome, but there is so much work to do when you create your own language.

The difference? In one, I was able to leverage an existing language to express the fundamental ideas of my domain in a more declarative style. In the second, I am writing an all-singing-all-dancing Turing-complete language that is divorced from the abstractions of a real problem. In short, one is a solution to a problem, the second is a problem looking for a solution.

My main point is simple. The line between a good idea and a bad idea is razor thin and all in the context. An idea may be good in isolation, but bad in situation. Figuring out the difference is what makes this engineering.