Checks Over $10,000 Require Two Signatures

work safe

When I get a check from SEP, there is a note and a blank line by Traci’s signature. It states that any check for more than $10,000 needs a second person to agree. While I’m sure there are some fraud prevention reasons this is a standard business practice, it serves a better purpose in our Demming based world view. We assume Traci is doing her best and has the truest of intentions,
but it sets a line on the sand for when she should get a collaborator. It is one thing for the IT staff to buy a new workstation for a couple grand. Once we are acquiring Oracle licenses it is nice to have a second person to say, “yes, there is no better way to achieve this goal other than to give Oracle everything in our bank account.”

We are reading Lean Architecture for Sep’s book club. It seems to be a good book because there is some agreement and some disagreement with its contents.

One such disagreement was over separating modules basd on teams. Why make such an artificial distinction? Isn’t it far too heavy to have to hand off a feature from a business layer team to a UI team to create a new feature? Yes. But that’s not what we are talking about. We are talking about distinctions of usage, not necissarily infrastructure. The graphs verses the import logic For example.

It was also mentioned that we have yet to talk about changing the architecture. The pithy answer is, of course, you change it every time you write any new code. The less pithy answer is any time another team is impacted by your code.

Crossing from one module to another is the trigger. Since it will cause changes on the code of another module, I should not make these design choices alone. It is a firewall against the inevitable descent in to the big ball of mud. It is the second signature line on the check.

No Comments

All I Want For Christmas

work safe


Blog BattleSEP 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.

No Comments

Motion != Progress

work safe


Blog BattleSEP 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.

No Comments

The Optimistic Programmer

work safe


Blog BattleSEP 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.

No Comments

Good Idea, Bad Idea

work safe


Blog BattleSEP 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.

No Comments

I Don’t Have Time

work safe

Blog BattleSEP 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.

1 Comment

Anatomy of an Ogre

work safe

Just a quick refresher of my last post; I hate layers and prefer the ports & adapters architecture I drew in the following picture.

Ports and Adapters

The next logical thought is probably, “Okay Mr. funny man. What the heck is going on inside that big green blob?” The same thing you should put inside the green part of the layers picture. Oh, the n-tier app guys don’t talk about that very much, do they?

The easy first draft of the green layer is to simply takes the objects you’ve mapped on to your data store, right? This works for many situations where the UI is essentially directly manipulating the underlying data. This is what Trygve Reenskaug had in mind when he codified the MVC pattern. It is also close to the Naked Object pattern.

But it falls down with complex inter-object interactions. The problem is just your normal run of the mill OOP as widely practiced, the translation of nouns to classes. You end up with jealous classes, classes with multiple responsibilities, and a bunch of untested business logic repeated in your controllers/activities. That means that your probably have an implicit relationship hiding in your code.

When these relations and interactions are important enough, they should be made explicit by creating An object to manage interactions. This is better OOP, but I’d you need some ‘further reading,’ try taking a look at Domain Driven Design or Lean Architecture’s DCI. They both get to similar places, but with slightly different paths. DDD shuns the anemic domain model favoring rich behavior; while DCI favors simple data objects that compose with traits to which own behavior to be used in context objects managing their interaction.

I’m currently leaning towards a DCI inspired approach. First, DCI is a when necissary approach. If simple MVC/MVVM/etc work, then lean towards that. When, however, a use case gets complicated enough, you reach for the DCI to simplify the controller code. I can’t claim to use pure DCI since not all environments in which I develop have ‘traits’ or some similar code composition mechanism, but what is interesting is starting to think about your controllers acting on contexts and not directly on the data. And a context is nothing more than your use-cases turned in to code. the other parts of DCI are the data and interactions. Data is just dumb data, what DDD calls an anemic domain object. An interaction is a trait applied to a data object enabling it to play a role. Interactions are not necessarily meant to be widely reused as each collection of context and interactions can be thought of as a bounded context. If you don’t have traits then consider this non-exhaustive list of the following fine options; a context specific subclass, a decorator, a wrapper object, or interface aggregation.

What’s good about this approach? For starters, it is far more testable since you are controlling the BL interactions with easier to mock interfaces. In addition, the explicit decoupling of regions of a complex page mean you will be more aware of interactions between those controls, and we’ve all had pages that start to have emergent behaviors and eventually end up sentient. You know, the one that keeps getting the change requests and bug reports.

Some further reading:

1 Comment

Software is Like an Oger

work safe

Software is like an Oger. It’s big, nasty, angry, rude, and has layers. In fact, have you ever heard anyone say, “Heck, no. I don’t want any software layers?”. Everybody loves layers!

By layers, I’m referring to a means of getting the one way ordering of dependencies and the separation of bounded contexts as a means of wrestling our code in to a workable and maintainable shape. If you want more, read the ‘teal’ book by Eric Evans. He does describe it in some detail.

For those not interested in Eric’s work, the idea is you group your application’s code by which ‘tier’ it belongs. Is this code for the ui? Is this code for persistence? Is this code for something else?

Like a linked list, each layer is only connected to layer directly below. The problem then becomes where to draw the lines. Sometimes it is clear. The UI shouldn’t know about a cursor, should it? Other times it isn’t so clear, like your core data model. Does it live outside the layer cake, or does it go all the way to the bottom?

Scalability can be gained using layers. The db layer can be stored procedures, the business tier can be we services, and the UI can be ASP.NET. Scaling is then a matter of determining how much of each tier you need. I’m simplifying a bit, but the decomposition helps with those decisions.

It also helps isolate changes. If we move from ASP.NET to Rails, I can still call all my web services and not impact the rest of the code. Conversely, I can replace the .NET web services with Ruby’s Sinatra, Erlang’s Mochiweb, or Haskell’s Yesode. Who would notice? Other than my team, who would be pissed that their BL is now “unmaintainable” since I’m a huge nerd and picked languages and frameworks I’ve not bothered to teach them yet. Actually, let’s be honest. Some of them I don’t know.

But what of your UI and Persistence are tightly coupled to your platform? Let us say, for the sake of this argument, I’m writing an Android application. The UI is defined by the platform. The storage is defined by the platform. So any layered business logic is transitively coupled to the UI. So much for one way dependencies…

This isn’t specific to Android. It’s iOS and WIn phone as well. Android just makes it easier for me to put on my pointy-haired-boss wig and ask, “Can I reuse that code in my Java ESB Tomcats Netbeans? Or do you have to port it to Eclipse?” He doesn’t care about tech. He just wants to save time and deliver value.

So let’s start by looking at what the layers look like.

Can we change the directions of the arrows? So the business logic is independent of the, formerly, lower layers? Then acknowledge our platform coupling? Then isolate our wrapping code?

This is the idea behind the “Ports and Adapters” model. I like it better than layers because it acknowledges something. That your bottom layer is sometimes coupled to your top so it’s artificial anyway.

Now we have our business code with no external dependencies. It can move from place to place. We can replace the storage engine, or the UI engine. As part of this, I can replace the UI or storage with stubs, mocks, and other test doubles. Which means I can cover all the really important stuff in my tests. In more practical terms, I can have my Android Activities be thin wrappers that inject dependencies in to my business code.

Want a real-world example of a win? I was reviewing a coworker’s code that was untestable because it called MessageBox.Show(...) and we decided we just needed to wrap those calls with an interface that asked the user a yes or no question. The implementation then uses MessageBox, but the unit tests can inject an implementation that response yes without hitting the UI.

The ports and adapters allows a lot of the decisions that would be handled in code touching the UI, and therefor difficult to test, to be decoupled from the UI, the database, and even the underlying file system.

No Comments

Usul’s Words Have Power, Part 3: Bounded Context

work safe

One of the important concepts in architecture is where to draw the lines in your software. What parts are relevant to what actions and what users? Bounded Context is a way of handling this mismatch.

Basically, it means that similar abstractions can get transformed on one side of a system boundary or another. It’s perfectly okay for these similar items to have very different fidelity and behaviors. After all, they may be similar things, but they are very different. Confusing an entity’s different data and roles in different contexts just adds more complexity.

Example 1 – Dinner

Let’s say my wife and I go to dinner with a friend we will call Jed. Jed orders a taco platter, a margarita, and the flan. I order 3 enchiladas, substitute refried beans for the spinach casserole, and a Diet Coke. My wife gets a taco and enchilada and just has water.

The server sends our order back to the kitchen. Once the food is finished, one of the waitstaff will bring the plates to our table, using seat numbers to pick who gets what at the table.

Once we are done, our server splits our ticket in to Jed’s bill and Mine. At this time, we don’t care about what seat number had what food, but only that Jed gets charged with the Flan, and I get charged with the Diet Coke. Jed pays with cash. I give our server my card.

Once my server returns with the receipt, I add a tip and sign.

Finally, my server reports the tip to the credit card company.

There are Four contexts in which the receipt is used.

  1. Plates for the kitchen to fulfill
  2. Plates and Seats for delivery
  3. Itemized receipt for verification by payer
  4. The unitemized credit card receipt

Are these receipts the same? Nope, buy they all map to the same seating. In modeling the system in software it may greatly simplify our code to model each of these contexts as isolated subsystems. Then when we hand a receipt from one subsystem to another, we translate to a specific model of what is a receipt.

Example 2 – Project Billing

Our company’s time is tracked using our bespoke time tool. We log each entry to the quarter hour and to a task code for a project. We also track what task item on which we were working at the time.

When it comes time to bill our customers, we roll each entry’s duration in to a bill. Oh, and the tasks may map 1-to-many task to Purchase order. And yes, a project can have several purchase orders that may or may not be used in parallel.

In the billing system, we don’t care about what hours were worked, but how many. In the time tool, what hours worked makes it easier for us to report our time.

When it’s time to generate our invoices, we translate from one bounded context in to a form useful for another bounded context. Especially since we don’t have complete control over our billing system since it is developed by a vendor.

Final Thoughts

The dinner example could be handled with using ‘views’ of an entity’s data. On the other hand, our billing example would definitely be made more difficult if we let our billing vendor define our time tool’s model. It’s a tool in the tool box, but it’s still not a golden hammer.

No Comments

Are You Baby-Sitting or Parenting?

work safe

Daniel Jalkut said that once you become a parent, it colors everything you do. He was talking about writing his first iOS app, Shush.

But a different thought crossed my mind when talking with my wife about the newest addition to our family. Did she feel like a mother? Did I feel like a father? We both agreed that it came and went. But if we really reflected on our lives, our wedding didn’t make us feel married. That had happened long before. And by inches.

What does being a father feel like to me? I feel most like a father when I roll up my sleeves and do the hard things. When I dealt with the Hospital Finance Department. When I drove home for 4 hours with my newborn in over 100 degree heat. When I change a diaper. When I clean a kitchen full of bottles and fill them with formula. When I do any number of household chores to ensure my wife dosen’t fall in to the trap of doing everything herself and she has time with her daughter.

Before becoming a parent I did some baby sitting. It was great until it wasn’t. Once the fussing began, I had one thought in my head. “I hope the parents get back soon.”

Once it was my kid the thought was different. I knew what it could be and how to solve all of it, except for just random fussy. But I have yet to stress during the fussing. She’s mine. I’m the one to make it all better.

What does this have to do with software? Ever been on a project where things go wrong and you have the thought, “Can I get transferred? Then this would end.” How about when things fall apart and the only thing you think is, “I got this!” Or even, “I don’t know if this project is possible, but I’m going to fly it in to the ground to find out.”

I’ve had all of those thoughts and I don’t think it has to do with whether or not I’m being professional or not. It has to do with Entitlement. By entitlement, I mean the psychological sense of belonging. It is mixed in to a few things, the most important is that your decisions and inputs are impactful both in the short and near term. If your are a clock punching monkey, you don’t love your work. The best you can do is baby sit a failing project.

If you are Entitled, it isn’t a feeling of being a design prima donna telling everyone what to do. Instead, it’s a feeling of being involved in the conversation of creation. It isn’t about being the loudest voice, but of being a voice that is respected and considered. It is then you feel like you are parenting a project. And a project you can parent is a project you can love warts and all. It is a project you will do everything for once it has growing pains.

No Comments
« Older Posts
Newer Posts »