Stored Proc vs Straight SQL

A quick one today.  Last night I was playing with some SQL I have been looking at, trying to finish it off so that I could wrap it into a stored proc for release.  It was taking about 15-25 seconds to complete, which given what I was doing was to be expected.  But after I put it into a stored proc that time dropped to 4-7 seconds.  Lesson of the day: when writing complex SQL, wrap it in a stored proc.

The Clean Slate

For the past 2 months I have been trying to reach a mythical state in our product backlog.  It is called "the clean slate". Now this might mean different things to different people, but to me it is clearing out the old jobs and tasks so that I can start the new year with nothing hanging on from the past year.

I know that this is something that I am not likely to achieve.  Nor even get close to.  A development department in an organisation is always going to have things to do.  If you don't, then it is likely that the organisation your working for isn't looking at going forward, but just consolidating its position.

So, what am I to do?  The only thing I can think of is to go back to that old saying. "Just Keep Swimming". I am still going to aim to complete the backlog list before the end of the year, and so (I hope) reach that clean slate on our development backlog. But if I don't get it done, I will not beat my self up (too much).  I will just keep at it.

Coding Rules

There are many rules when it comes to coding.  Some can only be bent (they get broken and bugs magically appear); the rest can be broken. The question is which rules are ones you can break, and which can you bend?  Here are some of my thoughts....

Firstly, try to make your code readable.  It might take a bit of getting used to, but try to write code in functions where each function is 10-15 lines long.  There might be a trail to follow to debug the code, but it is better than trying to untangle a mess of one big function that does everything.  It can, when you think about it, also lead to more reusable code.

Know what the function of the code is to be before you start. This is one that can be broken. Whilst we as coders can't know the in's and out's of everything, we do understand functionallity. So, before you start, understand the inputs to what your writing, how it should be processed, and the outputs.  Then take a step back and think about that you need to do. When I do that, it helps me to focus more on what I need to do, and usually means that I only have to do it once.  A trap is to get an outline and start coding without thinking about what you need the code to do.

Finally, be teachable.  In any code that I write, I try to always be of the mind that there is a better way to do it.  It dosent mean that I am always rewriting my code and so get nothing done, but it means that when someone has an idea as to a different way of doing something, I do my best to look at what they are saying objectivily.  Sometimes I am the one who is right, sometimes not.  Many a time fellow coders, and even on the odd occaision non-coders, have suggested changes to my code that would make the code faster, easier to understand or just neater.

Anyways, these are just a few of my thoughts on the rules of coding.  If you have any others let me know, this isn't ment to be a definative list, just some of my thoughts on coding rules.

A Level of Focus

One of the things that I am trying to learn on the job is what level of focus is right for which situation.  When do I need to focus on the details as apposed to taking a step back and looking at the "big" picture.  I was just completing a project that had been left open by the previous manager, and lets just say it went down hill pretty fast.

Looking back, the reason why it went down hill wasnt because of a lack of information, it was all available to me if I wanted it. It wasn't because of a lack of communication, there was regular communication.  It was because my focus was on doing what was always done, without really knowing what it was trying to achieve, or even what was done previously.

Now we were at the "implementation" part of the project, so I was focused on finishing off the "doing" part. What I should have done was taken stock of where things were at, which I did, but then I should have looked and understood the actual requirements.  This step back needed to be the second part of the taking stock that I was doing BEFORE I even started trying to implement the project. I assumed things based on my understanding on of what I thought happened prevoiusly. And therein was my problem.

I was focued on implementing my version of what I was implementing.  And my understanding was wrong.  Not totally, I even understood the overall goal of what the project was trying to achieve.  But the errors in my understanding ment that, at the end of the day, I was doing the wrong thing.  I should have taken a step back and changed my focus to the big picture then as I understood what was going on, then slowly focused more and more on the details as I checked that I understood correctly what was going on.

So, always remember to look at the biggest picture possible first on a project that you are starting to work on.  It dosent matter if you are starting a project from scratch, or picking up a project that is basicly done.  A quick glance at the data flow of the project, reviewing the aims and sitting down with the stakeholders (if you can) to make sure that you understand what you are doing from their point of view. Then refine your focus into the details to complete the project.

Just Keep at It

When projects start to look like they are going to be late, not be delivered or seemingly impossible to complete, there is one phrase that you need to hear.

"Just keep swimming, just keep swimming"

Yes, this may come from a children’s movie, but it doesn’t make it any less important. When all seams lost, don’t jump ship, just keep going. Focus on what you need to do next. Let people know about the issues that are causing the delivery date to slide, or functionality to not be delivered. As the saying goes, the only way to eat an elephant is one bite at a time.

And trust me, things are likely to get worse before they get better. It is the nature of things. Call it Murphy’s Law, it doesn’t matter. The main thing is that you need to keep at it. You can get though; just try your best to stay positive. Get positive people around you who can encourage you to get though.

Anyways, I hope that to those who are in the middle of one of those projects this lifts your spirits and your eyes can see the light (even if it is the size of a pin hole) at the end of the tunnel. And no, it isn’t an oncoming train. :D

It's all in the detail

Have you ever wondered why you complete a project and not gotten the pat on the back for all the hard work? When that happens to me I generally find it is because I have provided the overall concept of what was wanted, but the fine detail was missing.

By detail I mean the simple things like getting the User Experience right. This includes wording and correct spelling (yes, spelling is important); but also the pecieved way that features should work as apposed to the actual way that they work. It might do the same thing, but users generally know what they expect to see, even if they can't communicate that with you.

So, to finish, a word to the wise. While you need to make sure you deliver the project or functionallity, make sure you don't forget the details that will really make the UX just that bit better.

Geneva (and not the place with all the history)

Working on a Geneva prototype has been interesting. The extendability of the framework is awesome, using id management from multiple Security Tokin Services allows for an ease of managing multi-site users with no extra hassle. To understand what I mean, check out the Geneva documentation on the Microsft website, or the MSDN we site.

I would however say that there is somewhere that the framework may be let down. From what I gather, as a basic overview, the STS manages the identity, with the STS of the install, or primary STS, managing all the claims that the Geneva sever passes back to the client. But how does the application update the users details? For an instance using one STS, not a problem, point your appliaction management sections (web-links etc) to management functionallity in the STS. But with more than one STS? How, without making a claim(s) that contains the require data, would the Geneva framework handle that?

From my understanding, there are 2 possible solutions. One is to include the information as part of the claim. This would allow each application to manage the conections between the users and their identity management. The secnd is to use Geneva to send the details to, or show the form of, and have that communicate with the affected STS. How Geneva passed the update through to the STS is up to Geneva, and Geneva could through an exception if it were not possible. Also, the mechanics of the update could be defined at the creation of the trust.

Anyways, I am looking foward to using Geneva. From what I have seen it is a powerful identity platform that will have a great future. Who knows, the theories and practices behind Geneva could become the standard in multi-site identity management.

Understanding

Understanding what you need to do before you start a project is important, but not understanding it all shouldn't stop a project starting. Most project work starts with a phrase like "wouldn't it be cool if we could....." or “I would like to be able to ... so that I can ..." I'll let you fill in the blanks.

This start leads into a review of what exactly is required, how it might work, and what the end user can expect when the project is complete. The more complete the review and requirements list is, the better for the understanding of the people working on the project. However, you can start the project even without this review being complete. I would say that it needs to be 60-70% complete, but at that point the project work can start.

Here is the catch; to start a project where the requirements are not complete invites a risk that you might need to redo parts as the requirements get more and more refined. If you’re willing to take that risk, then there is no problem. Just be prepared to make changes as the requirements change, or when new ones are added.

Why start when you might just need to redo it all? If it is done well, and you are able to mitigate the risk, you can deliver the completed project earlier than if you waited for the entire review to be completed. The risk could mean that it takes longer as you are always redoing the work to fit the latest requirements.

Direction

Direction is very important. It is one half of velocity, is a part of vision, and can help you work out where you are. In a project situation, the direction the project takes starts at the very start of the project.

What happens when you don't have direction? There is no purpose, so why continue. There is no confidance that your doing the right thing, so why bother. Without direction you don't know where your headed. You don't know if your using the best tools to get the job done right, first time.

With direction, on the other hand, you can make decisions that are going to get you in the general vicinity of where you want to be. You can plan what needs to be done before you do it, not react to changing tides of what people want.

However, there is one important thing about direction. (Well, probably more than one, but this one is up there.) You can't just start moving in any direction. You need to know where you are headed, atleast generally speaking, so that the direction you take helps you get to where you want to go. Otherwise the gain you have in moving becomes a liability, and can get you into as much trouble as doing nothing at all.

Direction by itself is not good. It needs to be coupled with vision, or what the end goal is. This can be something simple, like a project and a deadline, or more complex like a 5 year plan. But without direction you will just be chasing your tail.

The Beginning

All things have a beginning, and this is my beginning for blogging....Not sure how I will go blogging, or if i will make more than one entry, but lets find out...