mike.mainguy

Face it, we've all been there...you're asked for an "estimate" that you KNOW you're going to be held to, but there are a hundred variables you have no way to control. The client is sitting at the other end of the table tapping their fingers and you think to yourself either: #1 "they don't understand, it's unreasonable, I don't have enough information", or #2 "Hmmmm, how much do I think based on my current information it might take?". At the end of the day, neither of those matter beyond the psychological value they have for yourself...the real question that matters is "how much is it worth to them for you to deliver this?". Yes, if you're billing time and materials, there are practical problems: If you estimate too low, your client is going to be disappointed that you couldn't deliver in the agreed to cost/time...if you estimate too high, you client might be happy, but often they also think that you cut some ...

A common question I get asked is "How do I make architectural decisions?" and my standard answer is "it depends". While it's a tongue in cheek answer, there is a bit of truth to it. While there are frameworks and methodologies to try and reign this problem in, the reality is that the practice of "software architecture" is inherently a mess and certainly a wicked problem . That having been said, I'll give some insight into "how I do it". First off, let me say, often many "decisions" are predetermined by your primary objective or have such a strong force behind them that there is little value in contemplating alternative solutions. A good example would be "which programming language should I use to develop an Android application?". You really have one decision and it's pretty binary: "Do I use java or javascript?" Yes, from a technical perspective it's possible to use ANY programming language (...

This letter is for all my friends, family, acquaintances, and others who feel they must support everything Donald J. Trump says without questioning it. I want to "tell it like it is". Before I get into details, I want to share some background. I was born and raised in Michigan, My Dad was a Fireman, Mechanic, Plumber, Heavy Equipment Operator, Cement Contractor, SeaBee...and probably 30 other things I don't know about...My Mom was, (aside from a homemaker that seems to be, even now, able to keep a house tidy and kids(and grand kids...and when we can get our grandkid out there...I'm sure GREAT-grandkids... able to not kill each other or completely destroy a domicile) additionally a jewelry salesperson, telemarketer, police dispatcher (or something like that), collections agent...and also...probably a bunch of other things I don't even know/remember. I personally have been a stock clerk, retail checkout clerk, telemarketer (last two my Mom wrangled for me), gen...

If you search for Software Developer Archetypes you'll find a large number of perspectives on this ranging from serious and helpful to lighthearted to frankly...kinda mean. I'm going to give a lighthearted example of core Archetypes I find when dealing with software developers. The Squirrel These developers are happy to jump between frameworks, languages, design patterns willy nilly and will be running 1000 miles per hour toward a "Haskell event processing framework to render static HTML files" and after 3 weeks/months, suddenly pivot, turn 135 degrees, and implement the remaining 10% (which will only take a couple days) in Ruby on Rails. By the end of a project, there are so many frameworks, dead ends, and partially done solutions that no matter what the original design was...their immediate solution for all problems is to "rewrite it in...something else". The Sloth These are almost diametrically opposed to squirrels, they often know "one thi...