mike.mainguy

note, this post was sitting in drafts for a few years ago and suddenly has become top of mind again in my post about git branching problems, I neglected to inform/expand on the "real" problem. Namely, Delaying integration is bad (tm) The History Waaaay back in the olden days, when folks used tools like RCS , cvs , and svn ...branching was...well downright difficult. Or rather, reintegrating the branches and/or cherry picking single commits without making things super complicated was very difficult. In those days, many folks adopted "trunk based development"...which meant...everybody worked on the trunk, and if you had conflicting changed you had to deal with it...RIGHT NOW. Moreover it made things like long running divergent branches a wicked problem when trying to bring back into the mainline...so most people just "didn't do it". Then Linus Torvalds Changed Things Well, in fairness, distributed VCS tools had been around a while, but he sorta ...

I read with interest an article about picking the right metric to incentivize desired behavior and thought I would add a little of my own personal insight. One problem with many (maybe most) software development organizations is that they inadvertently create perverse incentives , rewarding undesireable behavior and creating confusing and chaotic environments that, despite best efforts of all involved, seem to only on a hit or miss basis produce the desired result. Just as important, often the rewards are implicit and it isn't obvious that developers are actually being rewarded for the errant behavior. Some short examples of widely used, but poor metrics I've observed as well as some simple and arguably better alternatives follow. For example: Rewarding developers for "count of bugs fixed". Without accountability for who created the bug, this simply incents developers to release buggy half finished softwa...

The most important factor that contributes to a successful software project is ensuring that the development staff has a good understanding of the requirements. Incorrect requirements almost guarantee incorrect software behavior. Most often, however, the requirements aren't clearly incorrect, but rather they are vague, ambiguous, or make incorrect assumptions about the best way to apply technology to solve the problem. The original title of this post was "Writing Good Software Requirements", but I realized after writing the previous paragraph (irony noted) that writing good requirements is actually part of the problem. Having written software my entire adult life and much of my childhood, I've been most effective writing software for myself. This software has always done exactly what it was supposed to do (technical bugs notwithstanding) and the reason is because I had a visceral and complete understanding of the problem I was trying to solve and what factors...

One common theme in the development world is the vast difference in productivity between individual practitioners. Among folks with similar backgrounds, some are easily 10x more productive at delivering functional software. Software development is obviously not alone in having to deal with this, but I there are some particular attributes of software development that make dealing with this mismatch particularly difficult. The first problem is that many people seem to have the mistaken impression that if one has developers who produce output, then the output is simply the sum of the individual outputs. This is just not true by any reasonable measure and is a contributing factor to the reason many outsourcing projects end up a smoldering mess. Mathematically, each developer adds a cumulative amount of drag if the software they are writing needs to communicate with software other folks on the team are writing. As an example, suppose we have 1 developer working on a project, and he h...

I just read a great blog post about what it costs to write AAA games and the author used a term I love called " Bowfinger Syndrome ". Bowfinger is a movie starring Steve Martin and Eddie Murphy in which Bobby Bowfinger (Martin) tries to make a movie with only $2000. While a very funny movie, it hits home in the software development world in many ways. Too often, software projects fail because folks grossly underestimate the costs associated and then spend time trying to work around the lack of budget to actually finish the project. There are a number of reasons for this and I'll give a quick list: #1 A prototype of some software was written and someone extrapolates the costs to build the "real software". This is a mistake, prototypes are like hollywood cutout towns... they may LOOK like real software, but they don't necessarily WORK like real software. If you're eyeballing the hours necessary to build a prototype and trying to estimate effort ...

I read a great article about productivity and I think there is a side issue alluded to that needs to be addressed. A common problem is that the actual direct amount of time to do something is minuscule compared to the prep work necessary to be able to execute rapidly and effectively. The story I'm reminded is something like this: A man had a squeak in his floor and no matter what he tried to do he could not get rid of it. He finally called a master carpenter referred to him by a neighbor and explained the problem. The carpenter walked in, paced about the room for a minute, pulled out a hammer, hit the floor with it and the squeak disappeared. The carpenter handed over the bill and the homeowner was livid: "Are you crazy? You want to charge me $100 for just hitting the floor with a hammer?" Without missing a beat, the carpenter grabbed the bill, scribbled a few changes and handed it back. The bill now read: Hitting floor with hammer: $2...

Status according to the military in 1998. GAO report on SIDPERS3 success story from ada home. In short, SIDPERS3 was an abysmal expensive piece of junk, but nobody would ever admit it because there was no mechanism to stop the machine.

I recently watched a video of Nassim Taleb in which he explains the difference between anti-fragility and robustness in terms of economics and nature. A short explanation is that "anti-fragile" describes something that benefits from mistreatment as opposed to "robust" which describes something that can survive or tolerate mistreatment. After thinking about this, I realized a big problem with software development is that we expend tremendous energy trying to make systems robust, but seem to give little or no thought to making them anti-fragile. To counter this problem, I thought I'd share a few ideas on how to make software development more anti-fragile. #1 Embrace the idea that unexpected results can often be positive experiences. "Bugs" should be a thing of the past and should simply be observations about what the system does instead of an indictment of how poorly someone has implemented some other person's idea of how the software should...

Rational Application Developer Jabba the Hutt - BIG, SLOW, but also somehow powerful. You don't want to get on the wrong side of this IDE as you will be frozen in IBM consulting carbonite and NEVER get anything done. Netbeans Luke Skywalker- The hero who wins against all odds. However, In the software development universe, Luke actually turns to the dark side and joins Darth Vader. Visual Studio Emperor Palpatine - Having harnessed the dark side of the force, more powerful than you can ever imagine. Oracle JDeveloper Darth Vader - In the software world, after having turned Luke to the Dark side, Darth Ellison and Luke rule the Galaxy as father and son. TextMate Han Solo - Always seems to be there at the right time to help you out of a bind. No aspirations to rule the universe, but knows how to "get things done". Eclipse Battle Droids - There are millions of these, but they're all centrally controlled by someone whose motivations may be suspec...

Aside from supporting ruby, java, groovy, flex, and about a million other things, they actually have customer service. I don't mean "faceless mindless 3 levels of useless buearacracy" customer service, I mean "Holy crap, this guy WANTS to solve my problem" customer service. Recently I sent a note to intellij about an annoying, but not SUPER critical problem, to RAD or WSAD users (or just about any other software package), tell me the last time you sent an email and got this sort of help from a real person. Hello Michael, Please define "crashes". Serge Baranov JetBrains, Inc http://www.jetbrains.com "Develop with pleasure!" -----Original Message----- From: "Michael Mainguy" Sent: Tuesday, November 23, 2010, 7:29:23 PM To: feedback@jetbrains.com Subject: IntelliJ IDEA 'Feedback' Product: IntelliJ IDEA Build: IU-95.627 OS: Windows Name: Michael Mainguy Country: United States TimeZone: America/Chicago...

I've work now for a number of years in organizations of various sizes producing software. Having worked to produce wildly successful and effective solutions as well as hugely expensive boondoggles that are useless I ponder why sometimes things work out and sometimes they don't. Many folks claim that Software development is in it's infancy and this is the reason for the erratic results. If we're using human development as the metaphor for software development, then I think the current state is not even quite human yet. I think our state is somewhere more along the lines of a caveman or some other ancient common ancestor. Where we think we are Where we really are Or maybe here What makes things difficult is that people try to map processes and activities into a physical space. We talk about software as if we are trying to build a bridge or a house. Then we take processes used to perform these activities and try to shoehorn development processes into the...

In my new position, I've spent a large amount of time helping morph my development team's process into something that is a little more effective than what existed when I showed up. What we used to do was have a bunch of developers furiously coding on what they thought was important without actually getting feedback from the business. This led us to an interesting situation where we where spending hundreds of hours developing things that nobody really wanted (sound familiar ?) We've since spent quite a bit of time honing our skills and process to make sure we're working on things that the business (folks who pay us at least) think are important. This work has been rewarding, but not very technical in nature. I've finally gotten some time to play around with really technical stuff again and now remember why I got into this business. The fortunate thing I'm finally realizing is how EXTREMELY rare it is to find folks who can be effective at both managing devel...

Right now I hear rumblings that the "crappy" quality of our software is a direct reflection of our developers not taking the time to "properly" read the requirements. I quote those two words for two very important reasons. Number One: ALL software will be crappy... we're in the dark ages of software development. Accept it, if you think you've written perfect software, you probably didn't stick around long enough to have a hundred (thousand/million) customers. I've never met anyone (sane) who actually believes they wrote perfect software. Most of the time software is clunky and stupid 1/2 way through the project. The answer? Make your projects so small that having it turn into clunky and stupid 1/2 way through is no big deal because everybody knows you'll just fix it in the next iteration (i.e. next month). The only exception to this rule is in wonderland where people just proclaim victory even when the facts of failure abound. Number Two:...

Of all the relationships within a software development organization, the one that seems to cause the most friction is the one between the business analyst and the software developer. I find this is often caused by a lack of understanding about who is responsible for what. A BA where I'm currently working spelled it out best in a meeting a while back (Brian D). In our organization, the business analysts own the "who, what, why, where, and when" and the developers own the "how". Not sure how this maps into other people's organizations, but it seems to be a good starting point. Very often I read requirements with a lot of "how" in them. Examples of this sort of thing include: Create a web service to enable validation of item information Build a screen with 4 fields (create date, last modified date, historical cost, deleted flag What I would expect, as a developer is something more like: We need to be able to run the mainframe part validation routin...

Information architecture (IA) is a relatively new field that is absolutely critical for building effective information systems. The best definition I can find for IA is from www.interaction-design.org . The goal of Information Architecture is to improve information access, relevancy, and usefulness to a given audience, as well as improve the publishing entity's ability to maintain and develop the information over time This definition is OK, but it seems to be heavily biased toward software user interfaces and web design. Most folks, if they think of IA, want to know which button should go here and which field should be next to which other field. While this is an obvious and important application of IA, it is the equivalent of worrying about the order of the words in the title of a book, but ignoring the other 200,000 words INSIDE the book. As a person who working on projects that exist almost exclusively in the mind, a large part of my time is spent trying to get people to wor...

Ira Glass (of "This American Life" fame) has a 4 part VLOG on storytelling . I really enjoy listening to Ira when I have the opportunity and he has had some compelling stories. My personal revelation is that I should look more to people I respect and study them. As someone who never formally studied creative writing or storytelling, it was interesting that the mechanics of building a story outlined by Ira were more natural and easy to follow than the myriad of rules found in various English composition books I've read. I believe this the difference between trying to define a simple set of rules on how to master the mechanics of doing something as opposed to learning to bend your mend into the shape of a master of the art. A further revelation is that I realize that I am very often reading books about subjects written by people who aren't necessarily skillful or even successful at that particular subject. As an example, when reading about some very successful writ...

I just stumbled across a great article about the difficult transition from a startup into a more sustainable business. The elves leave middle earth I'm currently working in a place that is going through this change in the IT organization. Right now, we have a mixed team of heros and good performers. A key problem I'm having is that one of the managers is having a tremendously difficult time even fathoming the difference between these two modes. As a former hero coder, he spends his time fiddling around with code and inventing new "cool" requirements and almost zero time even thinking about how to keep the team performing. This has the predictable side effect of the team faltering and thrashing while this person sits around and bemoans how slow and confused the team is. Where I'm going is that if you're going to decide to change modes, you need to make sure you have a management team that is able to function in that mode. If it's necessary to move folk...

I'm taking a vacation day today. I woke up at 5:00 to take my daughter to school (trip to six flags), then went downstairs to put some finishing touches on some html I was fiddling around with to help with some new screens. While doing this a developer on my team started IM'ing me in a panic about a production problem that they where going to do an emergency deploy to fix. I attempted to calmly ask her to please explain the exact situation to me, but it came out more like "ARE YOU F'ING JOKING!? TELL ME YOU AREN'T SERIOUS!, WHAT THE HELL?". Whoops, no more coffee for me, my bad. So then I opened my email inbox and discovered no less than a dozen emails about about how the day before there was some sort of error that cropped up based on a specific data condition and stopped an extract process dead in it's tracks. For some reason, this software has run without exception for 2 months and suddenly yesterday at 5:00pm this data condition started to happen. W...

I recently sat down with a group of technical people and I made a statement that now haunts me. The statement was: "If a developer doesn't know exactly what they are supposed to do, they should just GUESS what they think should be done and move on. " Once the words left my lips, a technical team lead at the table paled and began to argue about how that statement was totally incorrect. I was puzzled for a moment, but then realised this person probably thought I was implying that they should not EVER go back and ask what should be done. In addition, I think they heard me imply that developers shouldn't ever ask questions in general. This was not really what I intended to communicate and in retrospect, my choice of words was unfortunate. To clarify, I obviously think people should ask questions, they should openly challenge requirements that are vague, ambiguous, or contradictory. More importantly, they should be free to use their best judgement in the absence of sp...