The last few years have been hell. They’ve left my heart broken and my soul shattered. I’ve shed more tears than I’d like to admit. Today I still cry but these tears taste so much sweeter. These tears are of joy as I found the thing that will mend my heart and repair my soul.
May I please introduce my daughter, Nicoletta Hope. 2:36 am. 6 pound, 12 ounces. 19.75 inches.
Published by Brian Mapes on June 23, 2013 in family
We are merely one week away from the due date and my daughter can literally be born any day now. When expecting your first child there is much to do and prepare for. Childhood is all about learning and I was thinking about all the things I need to teach my daughter. Here is my list so far. What have I forgotten?
How to make homemade pancakes
How to skip a stone
All the words to Billy Joel’s “Piano Man”
How to make homemade pasta sauce
We need each other
How to order a cheesesteak
How to boo like a true Philly fan
How to make a mess
How to clean up
Don’t belive everything you hear
You are priceless
How to use a drill
Righty tighty, lefty loosey.
How to program an if-else block and a for loop
Just because you can embarrass someone doesn’t mean you should
I’m not perfect
Your mother isn’t perfect either but she is close
When you are young you’ll think I know everything
As you get older you’ll think I know nothing
At some point you’ll find out the answer is somewhere in between
I’ll never put anything, including myself, before you
Please and thank you are very powerful
How to swim
How to build a snowman
How to fly a kite
Promises should never be broken
Sometimes promises get broken
How to throw a ball
How to swing a bat
It is not OK to be weak
Asking for help takes strength
Never stop learning
The world is not black and white
Nothing can make me love you more
Nothing can make me love you less
People will respect you more if you speak up
No one will respect you if you talk back
How to build a sandcastle
Don’t confuse love and like
How to change a flat tire
You may not be a princess but you should value yourself as one
Take pride in your appearance
Appearance isn’t everything
If you’re not 10 minutes early, you’re late
Forgive but never forget
Be able to be self-sufficient
Don’t be afraid to lean on others
If love is not unconditional, it’s not really love
Women can be strong, just look at your mother
Trying is more important than winning
Losing happens to everyone
When you allow losing to become a habit, you become a loser
Hard work doesn’t always pay off
Don’t be afraid to get your hands dirty
Be kind to everybody
Some people will try to manipulate your kindness
Some people think I’m too emotionally involved with sports
You can never bee too emotionally involved with sports
Don’t ever wear the logo of a non-Philly professional sports team
You can always come home
I like making up nicknames
Most nicknames I create don’t stick around very long
Family is important
Don’t confuse blood with family
How to dance in the kitchen
You will always be my baby girl
I will always love you
Published by Brian Mapes on June 17, 2013 in family
I’m not sure how many times I’ve been tasked with estimating the time it will take to complete a software development project. I’ve already accepted the fact that most of the time I’m asked to do it with unclear requirements, poorly described features, no definition of done, and minimal time to create it. The foundation for this estimate is already shaky but I document my assumptions, quickly describe some scope, and put together my best faith estimate. Far too often, someone, usually a non-technical person such as a project manager, sends the estimate back to me and says, “I need a better estimate.” What?
After seven years in the software industry, I’ve learned to translate “I need a better estimate” to “I need it done faster as your estimate will take too long and I’ve already promised the customer a delivery date even though I didn’t have enough knowledge to do so and now I’m stuck delivering it sooner than your estimate because I’m not going to be the bad guy and tell the customer it’s going to take longer than I said because I screwed up so you need to figure out how to get it done faster.” Whoa. Deep breath.
For the sake of this post, let’s ignore the unclear requirements, poorly described features, and no definition of done, and assume everything is crystal clear. Here is a simple, non-software related example: Bob tasks me with creating an estimate for Rob to drive from Philadelphia to a bank in Pittsburgh.
Tasked with creating an estimate, I take my personal knowledge of having previously driven from Philly to Pittsburgh, I check Google Maps, and I ask if anyone else had any expense with this trip. I then come up with a five hour estimate and add half an hour for contingency. In no time, Bob would be emailing me. “Five hours! I need a better estimate! I promised the customer Rob could get there in three!” So how is it my problem? Oh yeah, I’m the developer. So now I’m tasked not with creating a better estimate, but figuring out how to get it done faster. I always handle it the same way; I put the work back on the Bob.
There are only a few ways to affect a project schedule: time, scope, resources, and quality. Let’s take them one by one.
Time is very simple. Bob can always go back to the customer and ask for more time.
Many times the requirements are relayed without really understanding the problem. By figuring out why Rob needs to get to the bank in Pittsburgh maybe we can find a solution that will take less time. Maybe there is a bank in Harrisburg that will meet the same needs as the one in Pittsburgh? Heck, maybe there is one right in Philadelphia? Maybe Rob doesn’t need to go to Pittsburgh at all and this can be handled over the phone or on the Internet? Maybe someone already in Pittsburgh can go in his place? Again, I put it back on the Bob to go find out the actual problem.
If Rob is using a broken-down car that only goes 40 miles an hours and dies every 30 minutes then maybe a faster car would make a difference. My estimate assumed he is driving a car that can consistently do the speed limit and has average reliability, so giving him Ferrari isn’t going to make much difference. The Ferrari would allow him to go faster but we’ll assume Rob is going to drive at a reasonable speed. Two cars aren’t going to help much either. Maybe we have access to helicopter or airplane? Can we get a police escort? Again, Bob needs to go find out what additional resources we have access to and then I’ll revise the estimate.
Rob could run a few lights, drive down the shoulder, cut off other drives, take curves at dangerous speeds, and other crazy things to shave off time. Cutting corners is only going to make things worse. Rob might get pulled over, arrested, or injured. In any case, quality should never be compromised. I’ve been on development teams where quality was sacrificed to meet customer demands. It eats away at your soul. If you are ever part of a team where sacrificing quality is truly an option, quit immediately. You are not only sacrificing quality but you are also sacrificing your personal integrity.
In some cases you may need to actually improve on the estimate. Maybe your estimate for the drive from Philadelphia to Pittsburgh considered the scenic route though San Francisco. This isn’t the case most of the time. Improving the estimate is all about getting more information, agreeing on assumptions, better defining the requirements, and recognizing resource availably and constraints.
Published by Brian Mapes on May 28, 2013 in development
I was a child of the 90s and Microsoft did an excellent job of reminding me how awesome the 90s were.
While the video is fun it’s not enough to get me to switch back to Internet Explore. IE 6 and 7 were awful. IE 8 was a step in the right direction but still crap. IE 9 is almost passable as a real browser. IE 10 is actually pretty good but at this point I’m too comfortable with Chrome to think about switching.
Published by Brian Mapes on February 25, 2013 in technology
For years scalpers have been using bots to quickly purchase tickets before they are sold out. In turn, Ticketmaster and many other sites installed CAPTCHAs to determine if the ticket buyer is a human or a bot. CAPTCHAs can be difficult to decipher even for humans and have been annoying customers for years. Ticketmaster isn’t dropping puzzles altogether but rather moving to easier ones by Solve Media.
I’m assuming they are doing this because of customer feedback. I’m guessing they’ve got enough complaints over the years and they may even believe it’s affecting their bottom line. The customer in me appreciates this change as I no longer have to strain my eyes while translating obscure text.
The developer in me finds it even more interesting. This is a perfect example of UX and it also shows that you don’t always have to redesign an entire form to improve the user’s experience. Just replacing a difficult to solve CAPTCHA with a much simpler puzzle goes a long way.
Published by Brian Mapes on February 21, 2013 in development