Difficulties

We have a demo coming up on Thursday for what we've spent the last 6+ weeks working on.

I hate doing demo's. The scope of what we are actually talking about isn't clear. But people (ie, my bosses) need to be impressed and not disappointed . Hmmm, ok.

This isn't a technical audience, although it is an IT audience. When i explain things as they actually are, what we are demoing is seen as overcomplicated. When we deliver estimates, we are told it's too long. When i simplify, it's seen as redundant.

Need to find a fine balance between telling people how complicated things are, but also explaining that what we are delivering is complicated because of the problems with previous systems. We can't ignore the past.

I'm not going to be building a system that will be worse than it's predecessor.

It's not helping that i'm taking the lead, therefore responsibility.

I can't win. Yet i keep battling.

I'm fighting against myself.

When i think about what would happen if this project doesn't go ahead, i don't feel good about the qualities that i'm trying to push into the company. If they can't see why, then I can't help.

Scope

The scope of what we attempting is crazy. Once again i'm going to talk out my thought process to make sense of what's going on.

We are building our infrastructure for business process in our company.

I managed this week to deploy in about 2 hours a generic service for sending emails. this has always been a simple use case for SOA. 1 service on our network that has the single responsibility of sending emails.

done. for two years i've wanted to build it. only now with studying SOA, clean code and then the golden jewel of my professional life, NServiceBus. It's thing is amazing. Nothing else has come closer to demonstrating great code design. It's only now i've felt confident that committing to an architecture style of services is not going to dig a hole of maintainence and nightmare legacy. That's been my biggest fear of committing to technology. When i leave my employer i want positive things to be said about what i did in my time there. Not as the person that people curse when they go home at night because i've caused them pain.

in the midst of this leave request we've built two data views. leave requests that are mine and leave requests for my action. mine are ones that i started or were created for me, and forMyAction are ones that assigned to me || or are assigned to a role that i inherit.

we need to make these two views generic. view what is mine and what am i expected to be doing.

One place to go on the intranet to see these things. I don't want to give up and let the sharepoint system handle it. The coupling that we'd have to go through to get it in there is not something i EVER want to do. It goes against everything i've ever believed in.

The biggest problem for me is sharing hyperlinks between systems. if we have a generic system we need to keep the hyperlinks up to date.

therefore.... we have a service that is responsible for handling what the link for actions are.

I bought Rest In Practice a couple months back and in it they talk about HyperMedia formats. A JSON/XML representation of data, schema and behaviour. Therefore each time we send an object over the wire, we don't just send strings or dates or flags, we send over the applicable actions/commands that can be applied to the object via CommandNames and also hyperlinks to those actions.

Adding all the different types of behaviours into one large representation means A LOT of coupling and a lot of volatility. However as long as we keep the hyperlinks consistent in one system and design client systems to utilise them, all should be fine.

once these problems about responsibility are discussed, and attempts are made at to solve it, our interoperability abilities are increased 1000%.

Once we commit to making a system responsible for a part of the network then we mustn't duplicate that behaviour, anywhere, ever.

What i've been up to

So the agile journey has taken a back step. Rather than saying this is what agile is, i'm hoping that some persistence over time and explanation that we are implementing these practices in the hope that we become agile.

How?

We are trying to change the way development is done at our company by taking on a highly visible internal service we provide, the forms system. !

Why are we doing this? Why not use something off the shelf? We currently have Adobe Forms. It's old. We just bought Sharepoint. No one internally knows how to use it.

My boss is giving me a very large amount of rope with this.

Our dev team that focuses on c#/.net/asp/mvc/wcf/nservicebus, our web team that focuses on our intranet & internet sites, internal styling discussions with our marketing team, our analysts who can focus on the busi;.ness requirements and then some other internal IT people doing some project management(upper management wrangling). Guess what that sounds like? It sounds like a great cross functional team.

By our powers combined..... :) Upper management has wanted us to all work on something together. This is our great chance to actually do it.

So how can we create a form system. next post.

Thanks Jeff.

http://www.codinghorror.com/blog/2011/02/how-to-write-without-writing.html

I may try to publish my rants here more often. I'm doing so much internal discussion communication that i feel could help, not cause i'm awesome, but cause we've been running into problems that aren't well documented.

not that i'm the best writer/documenter. and that's exactly the point.

last week someone was asking me what i'm working on and was saying that communicating will be the most important part of what i'm doing. educating non-techies with some pretty complex ideas about architecture and development. these people think we are bullshitting them most of the time.

without explaining why, we aren't treating them very nicely. i don't like this.