The Look of Many an NDA

sheldonKeeping up with some Friday Randomness, I tweeted about this yesterday but thought it might be funny to share.

No matter where you work, you are probably subject to an NDA of sorts and then if you work with partners, you are subject to their NDAs as well so everyone stays on the same page.

And if you subscribe to some early developer SDKs, well then there is a whole slew of other NDAs for you to keep under your belt.

And then if you work with any early adopter platforms that those SDKs are built on, you might have another set of NDAs.

And of course we cannot forget the event NDAs which can supersede your platform and SDK NDAs but could be within the limits of your Partner NDAs.

The beauty of all of these, is sometimes they vary in completely different ways where one NDA can override and depending on the situation and context can be reversed the next time.

Not being a legal mastermind, there are times I am talking to a customer and when asked a question I quite honestly do not know how to answer and have taken to imagine that I must look something like Sheldon Cooper trying to smile when trying to mentally decipher what can and cannot be said.

 

Factors of Software Estimation – Your Knowledge

We are at the half-way point in this series and I thought I’d try to fit in this post while I wait for my 9GB of Halo 5 updates to be downloaded to my XBOX.

Experience and Understanding the Problem are two of the four pieces to being good at estimating what you are trying to do.  The third?  Knowledge.

You might say – “Well isn’t experience knowledge?” – no it’s not, experience is the act of gaining knowledge through doing estimation.  But knowledge can be garnered without experience, i.e., I can pick up a book and read all about Ruby on Rails or I can go to a blog and learn about PHP or attend a seminar and learn about .NET.  I haven’t used them in any real context but I have learned about them academically.

I know them, I know how it works.

Experience drives your knowledge over time, you get a project that has to use WCF?  You learn about WCF, probably more than you need for the project, and that is yours forever.

Beyond the technical where most of our experience might be focussed, is domain knowledge.  I can sit down and have someone explain a problem to be and I can genuinely understand the problem but have no surrounding domain knowledge or business context about what is trying to be done.  Domain knowledge is knowing the context around what you are trying to solve – “Oh you are trying to get this client to talk to that back-end, yeah the problem is that this legacy app that has no interface to it” or better yet – “You can’t talk to that application, not because you don’t know how to figure it out, but because it would violate our business compliance rules”.

Whereas experience opens the door for what you can do and understanding the problem shows you the path – knowledge, specifically domain knowledge, gives you the frame for you how you get there.  This is where you’ll start to hear the conversations around the whiteboard that go like – “I’m pretty sure that is not supported” or “We’ll have to talk to accounting before going forward” comes in.

Knowledge is, at many times, an additive component to your estimates as you trigger on work that will have to be done and built into your estimates to ensure they are completed, people you will have to talk to, etc.  The only time knowledge serves to reduce your estimates, is when you raise the issue and scrap the task completely out of some logic for which you already have.

We’re 3/4 of the way there and the last component might just surprise (or might not, that is completely possibly).

Factors of Software Estimation – Understand the Problem

Continuing on our this very recent series of Software Estimation where we first talked about Experience, now we are going to turn our attention towards the answer everyone says when their estimation is off the mark;

I didn’t understand the problem

How simple is that, understand what you are building?  When you think of a house being built, how much effort goes into the ground before a drop of concrete is poured?  Soil samples, digging – groundwork – this is what is laid when you are able to understand the problem.  Are the doors being installed when the floors have yet to be installed?  I pray they are not, but in software sometimes we tend to jump all over the place in an effort to “get” to the problem at some point.

How often have you heard;

I’m not 100% sure what to do here, but I’ll start over here and by the time I am done, I will have a good idea what to do here.

Two things are wrong with this statement; A) The developer is starting to code on something they really don’t have a grasp on and B) they are not confident that they will have a full grasp of the problem, even after having completed that work.  This is scary and what most often leads to coding and designs that started off with the best of intentions but is now just a partial design with a few hopes and dreams tied to it of maybe getting there.

When you don’t understand the problem this is where statements such as – “It should just work” – arise from, which do not elicit any confidence in those you are talking to.  Most will get the general gist of a problem and what the business needs but quite often there is a set of questions and/or steps that are just not being carried out which serve to help the developer better understand the problem.

Who is the User?

Who are you building this for?  Too often we ignore the audience which can radically change the work that we do – Are we building for the Internal IT guy with deep knowledge of a complex platform?  Are we building for the customer that can’t handle 15 text fields on their phone (even though it might work).  If you cannot articulate the end user for what you are building, then you do not know what you are building and at best you are taking a walk in the park at midnight during a power outage.

What’s the Platform?

When you’re building on a platform, the frame for understanding what you are building significantly changes.  When I code in PHP, it is very different then how I code in .NET – different IDEs, different libraries, different extensions, etc.  Whereas some might say you are now “locked in” to that platform and limited it by it, when providing an estimate I see this as the complete opposite where a piece of the unknown has been taken from me and now I know what I am working with and what I have to work within.  Think about it.  If you are estimating for the cloud or an on-premise solution (maybe the same product) your paradigm is going to shift resulting in a very different solution.

Draw it Out

As we grow as developers from newbies to juniors to intermediate to seniors we get lazy and think that we no longer need to write everything down, we have it in our head, we can start coding and get it done by lunch, etc, etc, etc.  No, no you can’t.  You might have some small successes along the way but for the big baddy problems, not a chance.  I live for markerboards and have one everywhere I do work – home, office, etc.  Draw it out, lay it out, draw the lines of communication.  That’s great that you can do it in your head, but take it one step further and now show your chicken stratch to someone and see what they think – can they read it, can they understand it, does it make sense or did you miss something?

This isn’t the end, we are only half-way there.

 

 

Factors of Software Estimation – Experience

Ask anyone in any field how long it takes to accomplish a task and you would hopefully get something of a straight-forward response in a decent amount of time.

Ask a Software Developer how long it takes to code X and you’ll probably be graced with a number of questions that could include, but not be limited to;

  • Have I ever worked on this component?
  • What language am I using?
  • Do I know this language?
  • Is this a hard problem?
  • Do I know the platform?
  • Do we have requirements?
  • Is this a high-priority?
  • When does it need to be done?

And the list can go on… and on… and on… you get the point though – estimation in software development is not an easy thing to do.  This topic is much too large for one post, so I’m going to break it into a few sections for this week, the first being Experience.

(more…)

Words I Strongly Dislike

Employee

a person employed for wages or salary, especially at non-executive level.

I strongly dislike this word, it is one of the few words that I go out of my way to use (BTW this definition is taken straight from Google).  If I am about to type it, I delete it and find another word to use; users, members, team, people, something, anything.

It takes away all other aspects of someone wanting to work with you, as though the only reason they are working with you is because they can monetary compensation.  The best part of this definition is the delineation between executive and non-executive?  So executives have a different definition for where they are employed and in this sense are not considered to be an employee of a company?

So many things wrong with this word, I try to avoid it any chance I get – when I look around the office at all the people that I have the opportunity to work with – this is the last thought that crosses my mind for their only reason to be here.

Boss

a person in charge of a worker or organization.

I have a problem with this word as well, it reminds me of the old saying “the buck stops here” quote.  Really, what we want, what I think everyone wants is a Leader, someone they can look up to on a project and/or team that will give them coaching when they need it and mentoring when they are struggling through a problem.  When they are staying late at night to get work done or coming in early in the morning, they want to see their Leader there, willing to help up and get dirty to get the job done.  A Leader leads through the trenches and a Boss watches from the sidelines?

Perhaps I’m wrong on both these words, maybe there is a place for them in our Lexicon, I hope not, and I’ll keep trying to expel these words from my vocabulary because they don’t do justice to the people I interact with and work on a daily basis.

Looks more and more like Fridays are now becoming the random thought of the week!