mike.mainguy

Git is Great! As a distributed source code tool, git is great. I love that when I'm on an airplane I can commit code without a wireless connection and have be able to unwind what I was doing. It was clearly designed with the "offline" model in mind. The idea I can create a quick branch, experiment, make massive sweeping changes, and just drop the whole thing if I realize it sucked...is AWERSOME! For a fact this puts it ahead of it's open source predecessors (namely...SVN, CVS, and RCS). But perhaps a victim of it's success What I observe, however, is that a lot of folks have taken up a development model where "everything is a branch" and we end up with roles like "pull request approval engineer" (not a real title, but if you end up doing that job, you'll know that your doing it). This problem happens when the number of public branches/forks reaches a count and complexity that far exceed any value they could have possibly served. ...

As a professional software delivery person, I like to keep on top of technology trends and "where the market might be going". Over the last decade and a half, quite a few languages and frameworks have come and gone and very few have had any real staying power. In order to be marketable and knowledgable in things that "people want to know", I generally find the Tiobe index and Google Trends to excellent resources in gauging popularity. In my analysis this year, I've established that relatively speaking, they are in agreement, so I'm going to use google trends (as the charts are easier to embed) to elaborate. Programming Languages Before digging into frameworks, there is the notion of "which language" is most popular? In this regard, java has been dominant and looks to remain so for a long time. While there is a downward trend, every major language has had it's mindshare diminished, I can only imagine because of the explosion of alt...

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...

After years of keeping it a secret, I'm finally going to let folks in on how to select software development tools. The great thing about my process is it applies to programming languages, frameworks, design patterns, and many other development aspects (even 'non software development' things). Here's the process: Does your current tool support your business goals? (things like: speed to market, cost, uptime, available programmers of the appropriate caliber) If yes, why are you reading this? you already have a tool, get to work. Can you modify your existing tool (keeping in mind the modification needs to take into account for business costs of modifying the tool) so that #1 applies? If yes, get to work modifying it. 90% of the time, I've found you don't need this step, but if you do...look for tools that more closely align with #1, try them, and go through the process again. There you have it! Five simple steps to the ultimate software development too...