The Binary Fallacy

Two roads diverged in a yellow wood,
And sorry I could not travel both
And be one traveler, long I stood
And looked down one as far as I could
To where it bent in the undergrowth;
-Robert Frost, The Road Not Taken

Binary Thinking is the process of thinking of things in terms of two opposites. You can either do A or it's opposite B. But that's it. In Neuro-Linguistic Programming, it's a technique for manipulating someone into making the decision you want by framing the choice as a matter of either the thing you want them to do or the opposite, presented as a harmful choice. In Cognitive Behavioral Therapy it's a pattern to be broken to help people gain more control over their lives. In Software Architecture it's a warning sign.



If stuck between two different ways of designing something, the answer is always door number three.

Why do humans think like this? Why didn't Frost just keep walking straight through the woods and not worry about the roads? Why didn't The Clash stop worrying about staying and going and just Rock the Casbah? I don't really know. I'm not a psychologist. I'm just a software architect who's familiar with Analysis Paralysis. The phenomenon of getting nothing whatsoever done because you're locked up in the decision making process. And after years of trying to figure out how to avoid this, I came to one inescapable conclusion.

When you're in analysis paralysis it's because every path you're considering is wrong

In my opinion, this happens when you realize deep down that you're looking at the problem wrong and considering bad options. You can't decide because you know your options are both bad.

So what do you do? Well, that's the tricky part and adages about in which part of the box to think aren't as helpful as people who use them think they are. If thinking of something new was as easy as the realization that we need something new then Elon Musk wouldn't be quite the icon he's become. The important question is HOW? First, you just need to stop and accept the fact that you need to come up with something different. Your first decisions were wrong and you need to set them aside. Don't go back to them. Then I recommend you look at the great Stoic thinkers. You start by asking "What is this and what is it for?" I often tell developers to answer those two questions for every application, for every class they build, for every database and table they create. And you don't build the thing in question until you can answer those questions.

Then you ask if a thing is needed or just wanted. If it's not something you need, based on the answers to the above questions, then you leave it out. You strip away the irrelevant. Often I find myself locked up because I can't find a clean way of integrating the irrelevant into my design. Once I stop and realize the piece that doesn't fit doesn't need to fit, things get easier.

I've often said that software development is 90% thinking and 10% typing. If you understand how to think clearly, how to organize your thoughts, and how to tell the difference between the necessary and the unnecessary then there's little that can keep you from being a great software developer.

Dear Entrepreneurs

"Regard your soldiers as your children and they will follow you into the deepest valleys; look on them as your own beloved sons, and they will stand by you even unto death." --Sun Tzu

An open letter to entrepreneurs, from someone who has worked for quite a few of you.

Normally, I go through a lot of examples and points and then summarize at the end. This one is important to me, though, so I'll give you the summary now. Up front.

Your company is your baby. Not mine. You're invested, not me. To me, you're a job. Just another employer. Unless you do something to get me invested.

In my experience, a good number of entrepreneurs don't quite get this. I get that your company is your baby. You've worked for it, lost sleep for it, and probably skipped a meal or two for it. To you, this is personal. But it isn't to me. Not right away, and not just because you hired me. If I'm going to be personally invested in your company, in your idea, you need to give both reason and opportunity to do so. And it's worth it. If you're just a job to me, I'll walk away as soon as a better one comes by. If I'm invested, I'll have to be dragged out.

To that end:

Just because you believe, doesn't mean I do.

Most software developers I've encountered fall into one of two categories. First you have the mercenaries contractors. They work for the people who give them the best compensation. And I don't just mean money. Pay, benefits, environment, all goes into it. But as soon as they see a better place, they're a developer-shaped puff of smoke in the air.

Then, there are the developers who want to work for the company they work for. Because they want to be a part of what that company does. Believe me- those are the guys you want. But you have to give them a reason. And that's the bit that, in my experience, many entrepreneurs overlook. They think that the fact that they know how awesome the company is, then any employee should, too. Automatically.

Look- I'm a software developer and I'm familiar with the territory. A lot gets asked of us, and we take a great deal of professional pride in delivering quality work. But there's got to be a better reason than "Because I said so". If I'm working 50-60 hours a week just because "That's policy", then I'm probably going to have my resume out in a couple of months. Definitely before my one year anniversary. If I care, then I'll do what needs to be done, but you have to give me a reason to care. 

I've worked at both extremes of this. One entrepreneur mandated 50 hours a week, minimum, 24/7 support, and made us track our time down to the quarter-hour. For few benefits, and frequent communication that profit sharing and ownership would only come to those who deserved it. Which was, at least at the time, no one. I had taken the job in order to gain a specific skill set. Once I felt I had it, I moved on. I had no investment in the company because the founder hadn't given me a reason to care.

I went to another startup. The CEO gave regular meetings, not just on how the company was doing but why they were doing certain things. He told us quite frequently that his vision was to change a market in order to put more power and more control, and thus more opportunity, in the hands of customers. He ended every meeting with "Welcome to the revolution!" He believed. More importantly, he got others to believe. Nights? Weekends? No problem. Answer questions while on vacation- sure. Why? Because I wanted that company to succeed- still do, even though we've parted ways. And even so, I'm a touch sad about having done so. Because I believed.

The Tipping Point

"You can push that car just a little too far any Sunday afternoon. And if you break your neck in some damnfool wreck, they forget about you soon." --Charlie Daniels, "Stroker Ace"

I generally prefer to work at small to midsize companies. The reasoning is fairly simple, too. I like flexibility. Not a complete lack of defined policies, mind you. Policies are important. They give companies a road map for, if not efficiency, then at least predictable inefficiency. But smaller companies tend to have the flexibility to know when you need to stray off the beaten path. Large companies do not. And there's a certain logic behind that. The more you do, the more you rely on that predictability. Policies have saved my neck a time or two. Being able to say "I can't start this effort because our policies have not been followed" has forced projects to refine requirements and has gone a long way to prevent train wrecks. But there's a flip side, too.

At larger companies, it's harder to change policies that either no longer fit, or need refinement from the original draft in order to produce the intended result. There's also more risk in proposing new policies, I think. There generally tend to be more people that need convincing, which tends to mean more people that don't want to "Change what has been working for us". It often comes to a point where it's easier to just live with the inefficiency than try to change it. Or worse, at least in some ways, ignore policy and try not to get caught.

Okay. So far, I haven't told anyone something they don't know. This is one of the factors that need to be weighed when deciding whether or not to accept an offer or to leave a company. It's, hopefully, one of the factors you investigate when interviewing a company. As an aside, please note that I didn't say "interviewing with a company." You're as much deciding whether or not to offer them your services as they are offering you a position. Never forget, you're a contractor.

The point is, while working for smaller companies, I've noticed a reoccurring phenomenon, which I've started calling The Tipping Point. As smaller companies grow, they start to take on more work and start to do more. At this point, I have observed two results.

If the company does not at least have some policies guiding their work, the company tends to collapse. There comes a time when it's simply too late to gain control of source code, whether because nothing is in source control or there's no structure. When it's simply too late to implement good project policies because stakeholders aren't interested in becoming properly involved in projects and that disinterest is too entrenched to change. When projects are dangerous to deploy because no one knows what anyone else is doing. At this point, while the company may struggle on, it's no longer possible to fix the problems, and the only smart move is to leave.

The second result I've observed usually happens when there are a modicum of policies in place, and is usually hastened by bringing in An Expert. Perhaps a new CIO, perhaps a contractor. The buildup, again in my observations, tends to start slowly. No deploying projects without communicating with other groups. Nothing terrible there. Common sense, in fact. Issues, bugs, and defects need to be logged. Again- why would you not? And we need to get a sense of how much we're spending on projects, so we need people to log time spend on projects. Not my favorite activity, but I can't deny the importance.

But then things grow. Communicating deployments becomes getting signoff from other groups before deploying. The bug tracking system becomes a full-on change management system designed to integrate with every step of any process. Except yours, inevitably. Rather than turning in time tracking spreadsheets, either a web app gets build, or you're to use a built-in feature of the change management system.

Finally, comes the tipping point. I wish I could say this is an exaggeration, but in one case, I was entering time into an application that had a database lookup for projects, yet my projects never seemed to show up. I also had to email the same to my manager. The time tracker was in half hour increments, but my manager wanted 15-minute increments. Every change, even to dev environments, needed to be entered into five different systems (again- not exaggerating) and cleared in a bi-weekly Change Control Board meeting.

And all this doesn't even take into account well-documented problems when you mix in an Expert Scrum Consultant. I think I've made my opinions on the subject pretty clear, but it's pointless to deny what often happens when Scrum policies get blindly applied. And that's the problem- policies getting blindly applied. The "Monkey See Monkey Do" style of "Best Practices".

It's a rare gem when you find an organization with the self-discipline to recognize a policy that needs refining or simply removed. Or temporarily ignored on a non-precedential basis. A good set of policies are a balancing act. Too many and you get buried under their weight. Too few and you get buried under your own weight. That's The Tipping Point.

Dear Recruiters

Start with what is right rather than what is acceptable." --Franz Kafka

An open letter to recruiters. Mainly recruiters for software developers, but I suspect much of these are reasonable requests for all sectors.

1. Please stop saying "Leading provider of". Sure- you want to give the idea that your client is A Major Player. Fine. All good. But using rehashed buzzwords doesn't convey that idea. The phrase is like the paintings in a hotel room. If you even notice them, they have no real meaning. Instead, tell me why your client leads their industry. What have they accomplished? How do they lead? Is it through use of new technology? New innovations? Say something meaningful. Something that will have an impact.
2. Please stop telling me how many years your client has been in business. This may be useful information for clients, but potential employees aren't looking to retain their services. They're looking for a culture that fits. Generally, the amount of time a company has been in existence is irrelevant. Instead, talk about the culture. Not everyone wants to wear a suit and tie and interact with a rigid corporate structure. But not everyone wants to work in shorts and sandals, sitting on a bean bag, and walking into a Director's office for casual conversation. Laying this out will help find candidates that are a good fit for the company.
3. Proofread your communications. Twice. When I see "I think you'd be a good fit for [Job Description]", I delete the email. Same with blatant misspellings. Anymore, any text entry application comes with an automatic spell checker.
4. Read the resume. The most recent position is where your candidate has moved in his career and it's reasonable to think that that the position on purpose. If your contact is in a leadership, planning, or strategy position, it's probably a waste of time to offer direct development work. Your contact has moved on to something else and it's fair to assume that, barring unemployment, moving back isn't likely to happen.
5. Be specific. "Maintaining large applications" or "Excellent communication skills" doesn't tell me anything. Again, these are hotel room paintings. What I want is a good snapshot of my day-to-day activities. Does "Sr. Application Developer" mean "Application Developer with a lot of experience"? Does it mean "Responsible for the work of a development team"? If I don't know, I'm less likely to take a chance. And that's exactly what you're looking for. Someone who will take a chance on your job offering being better than the current one.
6. This is likely somewhat out of your control, but stop with the "X years of experience". While I realize that your client is telling you that, under the misapprehension that years of experience is an accurate measure of anything, you shouldn't have to tell that to candidates. If you can't tell from the resume how many years of experience the candidate has in the necessary technologies, then the resume has been badly written.
7. Same with this "Degree needed" or "Degree or relevant experience needed" silliness. Aside from this not being any measure of anything important, it's pointless to include in a communication to a specific candidate. If your candidate doesn't have the necessary degree, don't bother. Likewise with "Degree or relevant experience". If your candidate doesn't have either, they clearly aren't a good fit.

So, what's the bottom line here? Much like the fact that a good candidate needs to stand out in order to be seen as a good candidate, recruiters need to stand out in order to be seen as a good recruiter. You can't afford to be a carbon copy of everyone else. You can't just be hotel room art, and you can't hand over a vague description with ubiquitous buzzwords and expect to spark any interest. Instead, you need to capture the candidate's attention. You do this through clear and concise communication of what your client is looking for. You do this by standing out.

A thought to keep in mind. All the advice recruiters give to job seekers about how they present themselves through resumes and interviews? That should apply to your communications with candidates. Especially your first contact.

Agile Isn't Dead

"Best practices are useful reference points, but they must come with a warning label : The more you rely on external intelligence, the less you will value an internal idea." ― Gyan Nagpal, Talent Economics: The Fine Line Between Winning and Losing the Global War for Talent

Agile isn't dead. It's not even on life support. However, to extend an analogy that everyone in the world should stop using, it does have a couple of CAT scan anomalies it should get checked out.. I've read a few tech opinion pieces to the contrary lately, so I thought I'd throw my hat in the ring.

+Hayim Makabee wrote an excellent piece on the subject, but one that I feel missed the mark somewhat. Jim Bird wrote on a finer grained level on the subject, and if you take them together an interesting picture starts to emerge. Starting with Jim Bird's piece, he lists several "Agile" practices that aren't needed. Skipping by a few points on which I disagree, his overall point is sound. Not all common practices are necessary. Hayim Makabee takes this a step further, rightly pointing out how "Agile" or "Scrum" consultants "over-simplify the software development process and underestimate the real complexity of building software systems". And I'm not really arguing that this "one size fits all" approach is a problem. I believe that the problem's source hasn't quite come out yet.

In short, the problem is IT decision makers. Not Agile, which is just a set of principles. Not Agile consultants, who are just selling a service people have asked for. And while we can discuss the moral culpability of someone "just selling a service", the fact of the matter is that people are buying the service. And those people are IT decision makers in pursuit of a concept that has made me cringe for some time now. Best Practices. "Best practices" are like the Dark Side of the Force. Quick, simple, seductive, and once you walk down it's path, forever will it dominate your destiny. "Best Practice" is shorthand for "What everyone else is doing", and while it's the sort of thing one ought to take into account, I've seen enterprise after enterprise implement iron-clad procedures based solely on "Best Practices", or rather "Just do what the neighbors across the street are doing". And before too long, you have Citogenesis, that curious phenomena where people think something is correct because people think something is correct.

Agile is a set of principles, and as far as principles go, they're pretty darn good. Agile isn't dead because these principles are still the best way to create software. But it really needs that dark spot checked out.

Healthcare.gov failures in leadership

"Good management consists in showing average people how to do the work of superior people." --John D. Rockefeller

"Good management is the art of making problems so interesting and their solutions so constructive that everyone wants to get to work and deal with them." --Paul Hawken

Yep. I'm back at this well. Partially because it's a great way to boost hits (I don't use ads, but I do have an ego) but mostly because I've been there. Not in a project this size, but I've lived the nightmare. Maybe someone that can affect this boondoggle

reads this and listens. Likely not. I have an ego, but I'm a pretty small fish. More important to me is that the developers and IT staff affected by projects like this understand the failings so that they know when to update their resume.

This one is coming from a New York Times article titled Inside the Race to Rescue a Health Care Site, and Obama. And again, whether Ms. Stolberg and Mr. Shear realize it, they paint a picture familiar to many IT veterans.

Failures of Testing

I've written about the technical failures of the development teams but what has been written in this article serves to underscore something all development teams know, but fewer do. Testing. From the article:

"To do that, they would have to take charge of a project that, they would come to discover, had never been fully tested and was flailing in part because of the Medicare agency’s decision not to hire a "systems integrator" that could coordinate its complex parts." 

"The website had barely been tested before it went live, so a large number of software and hardware defects had not been uncovered." 

"'There’s so much wrong, you just don’t know what’s broken until you get a lot more of it fixed,' Mark Bertolini, the chief executive of Aetna, said on CNBC."

Regression testing. Unit testing. User Acceptance testing. I can't think of a better way to talk about the dangers of not budgeting time to properly test your project.

"In Herndon, as engineers tried to come to grips with repeated crashes, a host of problems were becoming apparent: inadequate capacity in its data center and sloppy computer code, partly the result of rushed work amid the rapidly changing specifications issued by the government."

Code reviews and proper architecture concern would have prevented the "sloppy code" issue. The rest of this segueways nicely into my major point, thought.

Failure to understand a software development project

Clearly, project management didn't know how to manage a large-scale project. I've said before that the evidence could not be clearer that this project was managed Waterfall-style. And while the far-preferable Agile development style can also struggle with changing requirements, the iterative workflow, combined with constant checkpoints with the business stakeholders allows for better options for dealing with the fact of life that is spec change. Here are a few examples from my playbook:

"No, we will not change specifications in mid-sprint. If you want this change, submit it to the Icebox and give it a priority. We will then do the design and estimation work and add it to a future sprint."

"No. This is a two week sprint. We will not finish early. We will not rush. We have a planned amount of work that will take two weeks to deliver properly."

"No, we will not add to this sprint. The sprint covers an amount of work that can be accurately delivered in two weeks."

"No, we will not include this work into a sprint until there is proper user acceptance criteria attached. The delivered code will then conform to the acceptance criteria listed. No more, no less. I'm here to help you write good acceptance criteria."

Enforcing this kind of project discipline is crucial. It should be well-communicated up front. Everyone should know what an iceberg is. And once the expectation is set, that expectation is enforced. But even with that, the problem runs far deeper. Some quotes from the article really chilled me:

"Out of that tense Oval Office meeting grew a frantic effort aimed at rescuing not only the insurance portal and Mr. Obama’s credibility, but also the Democratic philosophy that an activist government can solve big, complex social problems." 

"'We’re about to make some history,' she (Ms. Sebelius,) said.

"...reveals an insular White House that did not initially appreciate the magnitude of its self-inflicted wounds"

As any regular readers know, my overall philosophy comes from Marcus Aurelius:

“This, what is it in itself, and by itself, according to its proper constitution? What is the substance of it? What is the matter, or proper use? What is the form, or efficient cause? What is it for in this world, and how long will it abide? Thus must thou examine all things that present themselves unto thee.”  

By itself and in its proper constitution, Healthcare.gov is a website that allows people to purchase health insurance. It is not a justification of a political philosophy. It's not about making history. Those are incidental. You cannot make good decisions if you don't understand the context for those decisions. You can't make good decisions about a development project if you see it as anything other than a software development project. And don't think for a second that minimizes its importance somehow. Most developers I know care a good deal more for their code than they do your politics. But if management mistakenly sees a project as some kind of ideological movement or as setting their legacy then they aren't making project management decisions.

Management culture

Finally, what may be the worst failing of the management of this project. It's culture. The standards management sets for its operations. The only place I've ever heard of management leading so poorly is in Dilbert. For example:

"For weeks, aides to Ms. Sebelius had expressed frustration with Mr. McDonough, mocking his “countdown calendar,” which they viewed as an example of micromanagement."

Mocking other stakeholders. Ignoring, for a moment, the notion of expecting professionals to not act like spoiled children, why was this behavior considered acceptable? Management sets the standard for how people act. A good manager understands this. A good manager sets an expectation of professionalism. Complaining is one thing. Open mocking should be the sort of thing people are embarrassed to do, or even to listen to.

"Contractors responsible for different parts of the portal barely talked to one another, hoping to avoid blame."

There's enough written about how a management culture of blame creates a toxic environment. Problems aren't addressed. People pass the buck rather than address problems. The concern is to not be left holding the bag, rather than making sure work is done well. Fear does not create quality. And clearly, this is not known here.

 "Mr. Obama, meanwhile, was under assault. After years of telling Americans, “If you like your insurance plan, you can keep it,” he was being accused of lying. On the night of Oct. 28, Ms. Jarrett, one of Mr. Obama’s closest confidantes and a guardian of his personal credibility, took to Twitter to defend him — and to shift the blame. 

“FACT,” she wrote. “Nothing in #Obamacare forces people out of their health plans. No change is required unless insurance companies change existing plans.”

The tweet touched a nerve; it was not the first time the Obama White House had used the insurance industry as a scapegoat. Ms. Ignagni’s (chief executive of America’s Health Insurance Plans,) members were furious. “Here it comes — we knew it would happen,” one executive recalled thinking."

 The Obama administration built support for the ACA by building hostility to the insurance industry, with whom they must now work. So, in essence, the Obama Administration has taken every opportunity to publicly condemn the insurance industry and is now relying on that same industry to launch not only it's centerpiece website, but the validation of their political philosophy. A management team that does not treat their vendors with respect will find themselves very lonely once they need their vendors. UnitedHealth and CIGNA have already "mostly shied away from the online marketplace" (From the article). To assume this has nothing to do with the administration's clear contempt for their vendors is folly.

I have a difficult time summing up my shock at the sheer number of leadership failures involved here. Not just in knowing how to run a software development project- clearly Medicare and the Dept. of Health and Human Services considered this a "Fire and Forget" project and that they were absolved of all responsibility to be involved once the project started. More disturbing, though, is the culture that management allows. Childish behavior and finger-pointing should not be acceptable. And that attitude starts from the top.

Health Care Exchange Project Pt. 3

"One test is worth a thousand expert opinions." -Wernher Von Braun

And finally the last piece of the puzzle. As a software developer, I find the previous types of project problems maddening. However, this last category boggles my mind. Perhaps I'm just an idealist, but I truly want to believe that this sort of thing doesn't happen anymore. Sadly, I read The Daily WTF far too often to really believe it. We are now down to technical failures.

Again, quoting from From the Start, Signs of Trouble at Health Portal

"Others warned that the fixes themselves were creating new problems, and said that the full extent of the problems might not be known because so many consumers had been stymied at the first step in the application process."

"'So much testing of the new system was so far behind schedule, I was not confident it would work well,' Richard S. Foster, who retired in January as chief actuary of the Medicare program, said in an interview last week."

We all know that maintenance, especially bug fixing, is the true bulk of any software development work. And we all know that testing is the heart of finding, and therefore fixing, bugs. This is not under dispute. However, I've been associated with so many development projects that ignore this basic principle that I want to weep sometimes. And it's always the same. "We don't have time to test because we're busy building features". Or "We'll focus on testing later". Or the worst, "We'll worry about bugs when they're reported by users". (Yes- I've been told that)

To be clear. Unit tests insure that a unit of code has a consistent result at any point in time. It doesn't insure that the code does what it is supposed to. It insures that what the code does hasn't changed due to other factors. Unit tests are how you do regression testing. At least, how you do it without resulting in Cthulhu-level madness.

User Acceptance Testing insures that the users can actually perform the tasks called for in the specifications. This doesn't happen at the end of the project. This happens at planned stages throughout the project so that testing happens on a manageable set of features. A set of features that can be easily documented, easily described, and easily managed. Failure to do this step before rollout is inexcusable.

And while we're at it, what about Exception handling testing? What effect does any given exception have? How is it reported, both to support and to the user? How are exceptions tracked? Testing isn't just about making sure the application works well. It's about insuring that it fails gracefully.

"The biggest contractor, CGI Federal, was awarded its $94 million contract in December 2011. But the government was so slow in issuing specifications that the firm did not start writing software code until this spring (Em. mine- MO), according to people familiar with the process."

I'm pretty okay with most of this, but the failure is so bad that it's worth mentioning. The award amount doesn't bother me. I'm also pretty okay with two years of requirements. This isn't like turning on a switch and watching everything work. This is a serious development project- far more serious than anything I've participated in. I would have been more surprised to see the award amount or the planning time significantly lower.

But read the bit I emphasized. Development didn't start at any point during planning. In other words, a project with this level of work and complexity was attempted Waterfall-style. Not Agile. Waterfall. In a project like this, the technical leadership deliberately passed on the ability to easily reach to changing requirements. And the ability to work on completed requirements as they become available. And on increased involvement between development and stakeholders. And continuous testing.

I'll take the heat for saying this- Agile isn't a buzzword. It isn't a topic for bloggers to discuss. And it isn't an alternative methodology. It's the only sane way of approaching a development project of any more than a trivial size. You simply can not anticipate everything ahead of time, and attempting to do so harms the project more than it helps. Case in point.

All of the problems the NYT article describes are serious. Any more than one or two of them will probably sink a project. The fact that people are reporting this many fundamental mistakes makes this an example everyone familiar with software development should understand. If only to protect your career.

Health Care Exchange Project Pt. 2

“No matter how good the team or how efficient the methodology, if we’re not solving the right problem, the project fails.” - Woody Williams

In my previous article I started talking about the New York Times article From the Start, Signs of Trouble at Health Portal. See previous article for the disclaimers that hold here as well.

In Part Two, I want to talk about the parts of the article that, to me, describe a major failure in project leadership. Not to be confused with executive leadership. In this case, the described failures in those responsible for the actual project leadership.

"Failure to plan is a planning to fail". It's a cliche for a reason. Starting a development project without a plan, or with an obviously flawed plan, is a massive waste of time and money. From the article:

"Dr. Donald M. Berwick, the administrator of the federal Centers for Medicare and Medicaid Services in 2010 and 2011 'The staff was heroic and dedicated, but we did not have enough money, and we all knew that,'"

From the beginning, we have a serious issue. The project wasn't funded.  The only way this works is if you have a plan to scale back what you can't pay for. The quotes in the previous article regarding executive leadership make this an impossibility, however.

 "Some people intimately involved in the project seriously doubted that the (Medicare and Medicaid) agency had the in-house capability to handle such a mammoth technical task of software engineering while simultaneously supervising 55 contractors."

"The political people in the administration do not understand how far behind they are." 

Well, now we have some insight into some of the executive leadership issues. Project management is supposed to be responsible for insuring that the correct groups are responsible for units of work and are responsible for reporting progress. It very much sounds to me like the project management team fell flat here. This is by no means unique to ACA, nor even to government development projects. I've seen, far too often, project managers who think their job ends with the kickoff meeting. Or who only schedule meetings and do little else. A good sign of a sinking project is negligent project management. Worse is project management that is unfamiliar with what the role entails.

"A round-the-clock effort is under way, with the government leaning more heavily on the major contractors"

"Worried about their reputations, contractors are now publicly distancing themselves from the troubled parts of the federally run project."

"Senior executives at Oracle, a subcontractor based in California that provided identity management software used in the registration process that has frustrated so many users, defended the company’s work. 'Our software is running properly,' said Deborah Hellinger, Oracle’s vice president for corporate communications."

How often have you seen this story play out? Lack of planning and poor leadership lead to "crunch times". As a result, development staff is required to work late. Demands raise past what is reasonable and soar up to the ceiling of what is possible. The result?  Discontent and CYA. The quotes above tell me that the contractors have already given up on the project and its leadership. Worse yet, the "blame game" has gotten into full swing. Blame doesn't happen when the project staff sees the project as salvageable. Blame only happens when the project is seen as a loss and people only want to salvage their careers. In a very real way, the blame game prevents problems from getting fixed.

Project management problems are a warning sign that is difficult to see. Oftentimes, poor project leadership isn't obvious until the project is well under way. At that point, recovering the project can be problematic. Tasks have already been assigned inappropriately, Reporting is either far behind or nonexistent. And at the worst, although I didn't see any evidence of this in the article, poor project management often involved a lack of clear project goals. This last is, in my opinion, the worst way project management can fail. If a project without clear end goals is allowed to continue, failure is the only possible result.

Health Care Exchange Project Pt. 1

“I have witnessed boards that continued to waste money on doomed projects because no one was prepared to admit they were failures, take the blame and switch course. Smaller outfits are more willing to admit mistakes and dump bad ideas.” - Luke Johnson

Let me start off saying that this isn't political commentary. If you want to talk about whether or not the Affordable Care Act (ACA) is a good idea or should be repealed, please go elsewhere and don't pollute my blog with political commentary.

Earlier today, I came across NYT article headlined "From the Start, Signs of Trouble at Health Portal" and written by Robert Pear, Sharon LeFraniere, and Ian Austin. Before going on, I highly recommend reading the article. I also found a very readable companion piece written by Megan McArdle.

The reason it caught my attention isn't that it is about ACA but rather the amount of project failures that I can relate to. The signs of common project management mistakes are so obvious, anyone experienced with software development projects will find themselves nodding their head with nearly every paragraph. This article doesn't describe a mere failing project. The failures described here are so blatant, so numerous, that I have to wonder if we're looking at deliberate sabotage. Or possibly the article is merely social satire.

The point of this isn't to slam the ACA, let me make that clear. The desired end of the project isn't what caught my attention. Nor am I trying to "discredit" the ACA. This is a real world study of how to run a software project into the ground and guarantee its failure before the first line of code is written. This article should, absent all else, serve as a warning to those undertaking software development projects, and indeed projects of any kind.

As this is far longer than my usual blog posts, I'm breaking it up into three parts, by what I see as logical categories of the project's failures. For the first one, lack of executive leadership.

It's frustrating when software projects are crippled by executive-level politicking. Executive-level leadership is foundational to a project's success. And like a building with a flawed foundation, poor executive leadership will destroy a project in unexpected ways. I have been involved in several projects that lacked executive-level leadership. All collapsed. Quoting the NYT article:

"Politics made things worse. To avoid giving ammunition to Republicans opposed to the project, the administration put off issuing several major rules until after last November’s elections. The Republican-controlled House blocked funds. More than 30 states refused to set up their own exchanges, requiring the federal government to vastly expand its project in unexpected ways."

"Administration officials dug in their heels, repeatedly insisting that the project was on track despite evidence to the contrary." 

"Mr. (Henry) Chao’s (Chief digital architect) superiors at the Department of Health and Human Services told him, in effect, that failure was not an option, according to people who have spoken with him. Nor was rolling out the system in stages or on a smaller scale, as companies like Google typically do so that problems can more easily and quietly be fixed." 

I see a few serious warning signs here. First, not all stakeholders were on board with the project. I don't care what rationale you use, if the stakeholders aren't on board, the project is doomed. This is as close to political as I want to get here. Neither the reasons the Democrats had for steamrolling the Republicans on the ACA nor the reasons the Republicans have for trying to kill it matter in this context. The unassailable, unarguable, truth is that if a major stakeholder want to kill a project then the project is dead. Ideology does not change this, nor does intent. Whether the result of the project is necessary, helpful, or detrimental is also irrelevant. And it is inexcusable for executive leadership to begin a project like this, through intent or ignorance of This Law, with such high level opposition.

Just as bad, however, is the unwillingness to acknowledge that the project is in trouble, but rather relying on the "Failure is not an option" method of resuscitating a project. Take a moment and count the number of times someone told you "Failure is not an option" or "Just make it happen" and it actually helped. Go ahead. Raise your hand if you got a number above zero. Anyone out there have their hand raised?

Didn't think so.

Attention all managers- these phrases do not solve problems, nor do they create an environment in which problems can be solved. For the love of all that is holy, stop using them.

Several reasonable suggestions are on the table. Postponement. Small scale rollouts, Google-style. The reasons given for ignoring these options are just about the worst possible. Executive-level politics.

Executive leadership enables development projects in ways that many people on the project never see. Because of that it's difficult to see when executive leadership is failing. Sadly, the results are less hidden.

Tips for Standing Out

"If you don't get noticed, you don't have anything. You just have to be noticed, but the art is in getting noticed naturally, without screaming or without tricks. --Leo Burnett"

Recently, I have been going through our family digital pictures. There's quite a lot of them, and I'm afraid that I haven't been great about any sort of categorizing or even avoiding duplicates. So, with literally thousands of digital pictures, I'm sorting, organizing, and moving them to cloud storage. In going through them, I started wondering. I had just gone through 30+ pictures of dolphins at a zoo and was currently looking at almost fifty pictures of a gift exchange at Christmas (more pictures than there appeared to be attendees), and I started considering the value of an individual photo in the age of ubiquitous digital cameras.

Sure- I could have organized the images in a given folder by general context and then subordered the images within a context by general worth. Color and lighting quality, view of the subject of the photo, etc. Establishing a baseline to determine which photos are worth keeping and which are not. And after a great deal of time and effort, I could have come up with the absolute best images to keep.

I didn't. I deleted something like 80 images because after picking out a few that represented the scene or event, even going through the rest of them to see if there were any other good images simply wasn't worth the time. The value of each individual image was very low. If it didn't immediately stick out as worth keeping, it wasn't even worth the time to look further at the image.

It shouldn't be difficult to see where this is going, but let's keep moving, shall we?

So how do we, as developers, stand out from the crowd. It's tempting to believe that consistently delivering quality work will to this, but let's face facts. In this world of development teams, project teams, and managers that have so much on their plates that things just naturally fall through the cracks, this simply isn't true. Nope- not even for you. (Mostly directed at 10 Years Ago Matt, who honestly believed just this.)

So what helps people stand out? When a manager thinks of your department or wants to assign a person to a task, what can make you jump into mind?

How to Stand Out

1. Don't be afraid to pitch ideas. Don't come off as critical and certainly make sure you aren't taking time away from something else. But don't be afraid to try. Code is best communicated through code so don't rely on the clumsiness of spoken word to communicate your code ideas. Build a demo. Cite sources. Make a pitch.
2. Talk to people. When you talk informally with colleagues or even, if your organization allows this, superiors, you have an opportunity to discuss ideas outside the delicate context of "Here's a change I think we need to make". This gives a degree of safety to the discussion- you're not proposing invasive changes, you're talking shop. You're exchanging ideas rather than making a pitch. Again- don't be critical and don't be a pest. But participate in the developer community of your office. People remember contributors. "Head down, mouth shut" often also means "forgotten".
3. Don't be afraid to ask for things. Is there a project you want to be a part of? Is there another role you'd like to fill? Ask. Maybe the decision maker will agree with you and maybe not. But your odds of getting what you want increase sharply when you communicate what you want.
4. In order to do #3, you really need to take this step. Be honest with yourself on what you want and what you can do. A central theme to everything I've said here is that you cannot properly use something you don't know and understand. That includes you. Want to become a Development Lead? Understand, then, your leadership abilities and how you can best display the skills necessary for the job. Asking is important, but if you can't show that you fit what you want, then you won't get what you want.
5. Be the guy that asks questions and offers solutions. Everyone can criticize. Even if they're not being critical, any good developer can summarize a problem. The trick is to be the one trying to help reach a solution.

How to NOT Stand Out

1. Brag. We've all created elegant code and we've all come up with clever solutions. And we all like to talk about them. But there's a line between talking about things you've done and bragging. If you never talk about your accomplishments, chances are that no one will recognize them. If you brag, chances are no one will care.
2. Butt in. Again, there's a fine line between offering help and butting in. Chances are, if you're the guy that always has a better solution and can't let even the smallest issue go by without comment, you've crossed that line. This, too, will make you stand out.
3. Criticize. You want to offer solutions because they think they can help. Great. But if you want to offer solutions because you think the current implementation is bad/stupid/incompetent then you'll definitely stand out from the crowd. Just not the way you want.

Let's face it. There are a lot of developers out there. There are even a lot of good developers who deserve to stand out. But it's not the job of other people to notice you. It's your job to be noticed for adding worth to what you do.

Why Bad Code Won't Die

Let's face it. Code goes bad. Maybe, due to technical debt, it started out bad and now it's time to pay the note on your debt. Maybe, due to a new version of your software platform, there's a better way of handling what your application is meant to handle. And maybe your application is now handling situations that were not taken into consideration during development, whether anticipating them was reasonable or not. Whatever the reason, what was once perfectly acceptable code often becomes obsolete.

The challenge isn't writing code that won't go bad. You do your best, with the realization that it might just happen anyway. The real challenge is getting the situation resolved, because you can't just charge in and make changes- at least, I hope you can't. It's a sad fact of the developer's life that projects like this may be necessary, but are often rejected, leading to frustration and a lack of confidence in leadership.

It's a common failing in communicating with others. You assume that things that make sense to you make sense to others and that things that have value to you have value to others. It's human nature, really, to assume that the context in which you view life is the context in which others do, too. Because improving the quality of your code is important to you, makes sense to you, and is just intuitively obvious to you, you tend to assume that it is to others. Then you construct your communication, consciously or not, along that assumption.

The problem is that most development managers and just about everyone higher than that on the corporate totem pole view project priority in a completely different context than developers do. And since they hold the final decision on whether or not a development project gets green-lit, it's critical to understand why "Yes" to projects, why they say "No", and the thought process that goes into that decision. If you can tailor your pitch to the way upper management thinks then you can at least communicate your need in a way they understand. This, of course, doesn't guarantee anything. But you at least avoid getting in your own way.

Developers tend to consider a well structured application as the end goal in a project and as the motivation for taking, or not taking, action. Which is good- that's what they're there for. The problem is that upper IT management rarely, if ever, evaluates projects through that lens. To them, risk is the key decision point. Not just the risk of breaking something else due to the changes, either. Risk to the project schedule as a whole. Risk involved in an application changing- even if it's for the better. Users get used to the way an application works and there's often resistance to change. The unfortunate truth is that, in the mind of an upper manager, "This is better code" never trumps "This is currently working". Attempting to approach a "Code Improvement" project from a technical point of view will rarely work. In fact, it has never worked for me. Not once.

The first thing you need to do is explain the necessity for the change in the point of view of what is important to upper management. If you can't do that, learn to suffer in silence because this change will go nowhere. Since upper management's priority is a low risk of interrupting business processes, it is critical to show that not making the desired changes will lead to a greater risk of interruption than not making the changes. Risk of application failure is a great thing to focus on. So is inability to support known, or likely, business needs in the future. If the current state of the code is no longer performing well due to increased load, point out the trend in increasing load and try to project a timeframe for the application no longer functioning. Are there upcoming needs that either can't be supported given the current state of the application or can be implemented in a greatly reduced time given a change? Have hard numbers and facts. State the known needs that can't be implemented and how that impacts the business. Show how a project can be completed more quickly if the desired change is done now. Remember- upper management cares about how well the IT department, as a whole, can support business needs as a whole. Present your case in terms that are important to your audience.

Second, have a plan. Don't just outline a problem and dump the mess in someone else's lap. Explain how the problem can be fixed. Go on from there to how long you think it will take- remember, your audience is thinking in terms of a schedule of many projects. Scheduling an unanticipated project impacts the rest of the project calendar. Make sure your audience understands the impact and that the impact is worth it. Then outline the risks. This is important because as soon as you give your opening argument, your audience has already started thinking in terms of risk. Then present how you will handle that risk. Will other applications be affected? How will you minimize the impact on those applications. Will this change business processes? How can IT work with the affected business units to make sure they understand how to interact with the changes. What happens if something goes horribly, horribly wrong? What failure points will you be looking for and what will you do if they do fail? How will you minimize the impact of a massive failure on the business, how will you fix the failure, and how much effort might it take? How will the project calendar be affected, what projects may have to be put off in order to do this, and what can be done to minimize the overall delay?

None of this, of course, guarantees success. I've made pitches like this and heard the equivalent of "I understand, but we want to focus on new feature development". Or, "I'll take a closer look at this and see if we have time on the project calendar." Which is often a long way around of saying "No". Sometimes upper management simply isn't interested or just doesn't want to accept the risk. This happens. But management is never willing to accept risk they don't understand or change that doesn't seem beneficial. It's your job to communicate the need to fix bad code in a way that the decision makers will consider a high priority. If you understand how the decision makers think, you understand how to communicate with them.

Which, if you think about it, goes for life in general as well.

Best Practices

"The cart before the horse is neither beautiful nor useful." --Henry David Thoreau

You're doing account signup forms wrong.

Okay, I should say "If you're doing account signup forms, you're doing them wrong." and while logically (if not grammatically) more accurate, I thought it made less of an impact as an opening statement.

The problems with most signup forms are myriad. Why do sites force you to enter your email address twice? Mobile platforms have figured out that masked password input boxes aren't always necessary, and give you either an option to turn it off or give limited clear-text viewing of your input. Websites haven't gotten the memo. And if I see one more site serving up a picture of what can only be described as a dust storm and telling me to type in the letters in the box to prove that I'm human, I'm going to flip and write a blog post about it. Just. Stop. It.

Now, as I hope I've made clear in my writing, I don't care about forms, CAPTCHA, or even UX issues. Or rather, I care about them only in the context of the thought process that went into them, and that's where account signup (and often account management) process fall flat. It's due to a very insidious concept known as "Best Practices".

I hate best practices. As soon as that phrase is first used in a requirements gathering meeting, I step on it like I would a roach. "Best Practices" used to refer to process that the industry had adopted, formally or not, as the best way known at the time to approach a problem. That, I have no problem with. What I have a problem with is the fact that "Best Practices" doesn't mean that anymore in software development. Anymore, it means "What is everyone else doing?" Which leads to lazy planning. Which leads to bad results. And I really hate bad results.

"Best Practices" are insidious. Because it's assumed that these practices are used because they're the best way of approaching a problem, people stop thinking about solutions as they apply to their specific needs. Any time you start implementing solutions without considering whether or not that solution is actually a solution to a problem you have, you have at best added unnecessary complexity to your project. At worst, you end up implementing code that hurts you in the long run.

Worse, though, is that no one ever advances that body of knowledge when "best practices" are applied blindly. Since everyone is using the same solutions as everyone else, no one thinks up new ways of solving problems. In the UX arena, this results in carbon-copy sites that don't stand out and present all the same inconveniences that the other sites present. In the web security arena, it's even worse because you are implementing that worst kind of security. The kind that makes you feel secure without necessarily offering any concrete benefits. Since the "security" principles that are labeled "Best Practices" are applied blindly, you don't know if the implemented solution solves the problem at hand, much less whether or not the problem at hand is one that needs solving in your context.

As an example, let's take password masking. Many mobile devices briefly show in clear text the latest character typed into a password box. This is not new. In fact, I've read people claim that Apple innovated that idea for the iPhone, but my Palm 600 did that. This idea is ten years old and the web world still hasn't caught on. It's become an expected inconvenience because everyone is looking at everyone else's paired "Enter Password/Reenter Password" boxes. Even worse, this is billed as a security measure without asking whether or not this is a *necessary* security measure. Does it really hurt anything if a site offered a way of viewing your password in clear text, thus avoiding the usual paired password box routine?

Am I saying that these measure are all unnecessary? Absolutely not. Except when they are. And if requirements are being gathered in the context of your needs and your solution, then it becomes obvious what you do and don't need. The problem is that "Best Practices" are applied backwards. The solution is selected and the problem lays unexamined. Software development is merely implemented problem solving. You can't solve a problem you have not examined.

Painting Fences

Imagine this exchange, if you will:

Homeowner: We need to to paint the outside of our fence white.
Contractor: No problem.

(2 weeks later)

Homeowner: I know we asked you to paint our fence white, but now we need it painted red.
Contractor: You don't like the white?
Homeowner: It's not working for us, and we'd like to try red.
Contractor: No problem.

(2 weeks later)

Homeowner: Okay, sorry about this but now we want our fence green.
Contractor: Sure, I can do that, but I have to ask. Why the color changes?
Homeowner: The neighbor's dogs bark all night and we're trying to find a fence color that calms them down.

Silly, isn't it? Ridiculous, in fact. And yet, a conversation in which I've participated more than a few times in my professional career. It stems from the business side of a software development project telling the development team what they want, which should be avoided at all costs. Yes. I just said that. The business shouldn't be allowed to tell development what they want. The reasoning is fairly simple, too. They don't know what they want and even if they did, they don't have the technical vocabulary to communicate it.

What the business does know is what it needs. There's a pain point, a failing, an inefficiency, or a breakage somewhere that needs to be resolved. That's what they should be talking to you about. They need to show what the process is now, what they don't like about it, and what it should look like when the problem has been solved.

There's a subtle difference between business needs as requirements and implementation details as requirements. Subtle enough to go unnoticed sometimes. Subtle enough to even seem reasonable. It seems almost reasonable to say "The account creation form needs to validate the format of the email address." Or "I want to be able to delete accounts". But it's like two lines that aren't quite parallel. Extend them out for a long enough distance and they end up in very different places.

Let's take a look at the two examples above. Validating an email address seems reasonable. Necessary, even. After all, you don't want users accidentally putting in a bad email address, right? If we're going to have any success at all, we're going to need a regex.  Something along the lines of

bool isEmailValid = Regex.Match(emailAddress, RegexString).Success;

Problem is,writing that regex is harder than it looks. Bigger problem is that it likely doesn't solve the underlying issue. Note, I said "likely" because we don't actually know what the real issue is. All we know is that we need to validate an email address. There's no mention of why. But if the underlying issue is making sure that the user enters a valid email address, which seems reasonable, then this doesn't actually solve the problem. It's very easy to write a regex (okay- let's face it. Search for a regex and copy/paste it. C'Mon- you know you do it.) that doesn't properly validate an email address, and prohibitively expensive to write one that does.

This solution falls even shorter of the actual need if the need is to make sure that the user enters a valid address that they have access to. Which may be what the business meant. It also may not have been what they meant, but would agree this was the proper direction if they had communicated their need, thus giving the architecture team the chance to respond and ask questions. So, due to a solution disguised as a requirement, we have a solution that will likely either validate malformed email addresses or reject valid addresses and does nothing to make sure the user has access to the email address. So what, in fact, have we actually accomplished?

The second example seems pretty reasonable, too. After all, do we really want dead accounts laying around? And besides, what if there's a user that we don't want accessing their account anymore? It's not like this will be an every day thing, but just in case. The problem here isn't whether or not a solution can be implemented, it's the repercussions that are not being considered. What do we do with the order history of a deleted account? If we keep it, to what do we associate the orders? If we delete it, how do we explain the discrepancies in financial reporting? Or inventory levels vs. newly adjusted sales numbers? What if you need to process a refund? Good grief, what if you need to undelete the account? This requirement is like an early 80's Buick. As soon as you fix something you uncover two more problems.

There's no easy solution to the problem. The business side needs to be careful to communicate needs. User stories are supposed to help with this, but they only help if used properly. Here's where a good BA will come into play. A good BA can make sure that user stories aren't reduced to endless copies of "As the product owner, I want {technical solution} so that the product works properly". The three parts of the story are necessary because, when used correctly, they define a need instead of a solution. And the architect needs to ask himself, for every requirement, "What is the need behind this?" If the answer isn't immediately obvious, there's a good chance that you're dealing with a solution disguised as a requirement.


(Ed. note: If the customer requesting the fence painting is Mr. Miyagi, just do it.)

Clay Pots

"Perfection is not attainable, but if we chase perfection we can catch excellence." --Vince Lombardi


I tried to find a link to the experiment, but could not. Perhaps it’s allegorical. However, I read once about an experiment done by a pottery teacher. She divided the class into two teams. She told the first team to make the perfect clay pot. She told the second to simply make as many clay pots as they could. At the end of the experiment, the perfect clay pot was indeed made, but not by team 1. As it turned out, the constant iterative practice by team two trumped the careful work of team one.

NOTE: Thank you to +Dave Aronson for pointing me to the link I couldn't find!
http://kk.org/cooltools/archives/000216
He also has some thoughts on the subject at http://www.dare2xl.com/2010/08/just-do-it.html

This is not an article about getting better at software development the more you develop software. If you’re reading this, you already know that. No, this is about software architecture and building the perfect design. Which, as I explained in my first article, doesn't exist anyway.

Every Software Developer/Architect/Engineer/Whatever that I've worked with has shared a couple of characteristics. They want to get their work done right, and they take time to think through what they're doing before they do it. Both of which are commendable. The problem comes when this leads to Analysis Paralysis. When the process of thinking things through in order to make the perfect design deadlocks the developer and he can't move on.

When that happens to you, remember the clay pots.

Agile methodologies such as Scrum and XP were developed, in part, to avoid analysis paralysis at the project level. With a focus on action and testing the results, agile methodologies seek to create the perfect pot by creating pots until they get it right. As it turns out, this technique works just as well at the individual level.

Sometimes the best way to break through design indecision is to just start writing it. Build the class stubs, make them interact, and build unit tests around them. How well does it work? How badly doesn't it work? Then consider what worked, what didn't, refine your ideas and start over. Wash, rinse, and repeat until you’re happy. Or at least satisfied. Or at least still on this side of “I’m so frustrated I’m about to throw my laptop through a window”. Seeing how the design plays out and forcing yourself to refine and retest can often lead to better results than trying to think through every detail in advance so that you create the "perfect" design the first time.

Don’t get me wrong. I’m not advocating against careful thought. I’m not saying “Don’t plan” or “Don’t think”. And I'm certainly not saying you should just throw code against the wall until you get something that looks workable.

Consider the T.V. show "Dr. House". His beliefs that there is one absolute right way of handling a problem is completely detrimental to software development. But one of the few things that I agree with Dr. House *in practice* is his insistence on thinking through a problem before acting on it. But if you remember the series, he follows the clay pot model. Think. Do. Refine. Think again. Continue until done. You won’t get it right the first time, and you should be very suspicious if you do, so don’t grind on it. And I love his attitude that making mistakes is expected. No one cares, as long as your end result is solid. 

Here’s the thing I tell architects and developers alike. There are no points for style. No one is counting code check ins, no one is counting compilations, no one is counting design iterations, and no one cares as long as the end product is a good one. Until then, if you have to slam it in with your knees, do so.

Often, you don't know what works until you've seen something that does not.

You're A Contractor

"If it looks like a duck, and quacks like a duck, we have at least to consider the possibility that we have a small aquatic bird of the family Anatidae on our hands." --Douglas Adams, Dirk Gently's Holistic Detective Agency

If you're not reading Hayim Macabee's Effective Software Design blog, you probably ought to be. His Continuous Learning post is an important read and got me thinking. The article is about how important it is for software developers to never stop learning and improving their skills. Which is true and something worth reminding people about periodically. But as I read, it occurred to me that continuously learning is only half the answer.

I started out in ColdFusion professionally, back when ColdFusion was actually a profession. (Sorry, Ben) There are a myriad of reasons why ColdFusion isn't a viable career option, some fair, some born of real misconceptions, and all irrelevant, for practical purposes, to a developer who has realized that he's in a dead end specialty. The reality of the situation was that I was working in a rapidly shrinking circle and it was time to get out.

Learning a new language isn't difficult. Getting someone to hire you for it is something else altogether. My employer at the time was generally unwilling to pay for training and even less willing to put new technologies or techniques to use. I had to rely on personal projects, online learning, a ton of reading, and the one Java bootcamp I could convince my company to send me to. I eventually found myself in a position where I was competent in both C# and Java and felt I could handle a development position using either language. But with no professional experience in either, getting a recruiter- much less a hiring manager- to agree was a challenge. And so I found myself in a Joseph Heller Catch-22. I couldn't get the professional experience I needed to get out of ColdFusion without first getting out of ColdFusion.

I have a lot of people to thank for helping me break out of that career black hole. A recruiter who knew me well enough to trust me when I said "Just get me the interview. I promise you I won't embarrass you". A hiring manager who believed me when I said "Learning C# is easy and you don't have to teach me how to be a software developer." A technical lead that didn't believe me when I said that and sat for almost an hour making me prove it. And finally (Warning- blatant sappy moment) a dad that taught me to bet big on myself.

The problem I had at the time was that the way I was viewed professionally did not match what I needed it to in order to advance my career where I wanted it to go. It was +Tom Searcy at Hunt Big Sales who put the problem, and the solution, in sharp focus for me. Everyone is a contractor. With that simple phrase, he put into focus everything that had been a problem for me when I was breaking out of the ColdFusion world. Ultimately, I work for myself, you work for yourself, and it's up to you to make sure that how you are seen professionally is how you want to be seen. This isn't about "job hopping" and this isn't about always being prepared to switch companies. This is about making sure that you can direct your career the way you want to direct it.

You direct and take control of your career path by both learning what you need to know and by getting seen being the kind of professional you want to be. Neither step is useful without the other. It hasn't been a good idea to try and bluff your way into an IT career for a long, long time now. And it does little good (Trust me!) to know how to handle the position you want if no one sees you as competent. You must do both. Hayim Macabee has outlined some excellent ways of handling the former. Thankfully, there are now more ways than ever to manage the latter.

Social Media

Not so much Facebook as Google+ and Linkedin, although that might just be my personal preferences. If you want to be seen as a skilled software developer, start by looking at the information people can readily gain by looking you up. Does it show you participating in software development discussions? Are you interacting with others? Asking questions? Offering advice? Joining, or even starting, conversations?

No? Then why not? A duck doesn't have to tell people that he's a duck. He quacks.

Projects

It used to be that recruiters and "resume specialists" would tell you to leave personal projects off your resume because they were no more relevant than hobbies in the job search world. Whether or not they still do, personal projects can be made relevant to how you are viewed in the industry. We all know that developers learn by doing. Now, it's easy to show people that you're both learning and doing. Got a project you're working on? Put the code on GitHub. Tell people what you did, why you did it, and ask them to use it. Is anyone going to hire you over a project you put out on GitHub or BitBucket? No. Probably not. But if you use these tools, then you are getting seen acting as the kind of software developer you want to be. It's part of managing your professional perception.

Blog

Go start one. Now. No- wait. Finish reading mine, then go start one. Be seen publicly talking about the things you want to be known for. Then tell me about it, and I'll put it on the list of things I read. And then I'll write about the stuff I think about when I read what you have to say. Talk about the subjects on which you want to be known as an authority. Then go talk to other people on their blogs.

Software Developers have to be continuously learning. But that's half the issue. If you want to be a duck, it's time to get out in public and quack.

The Ant, The Tiger, and The Programmer

“You have power over your mind - not outside events. Realize this, and you will find strength.” --Marcus Aurelius

“My weaknesses... I wish I could come up with something. I'd probably have the same pause if you asked me what my strengths are. Maybe they're the same thing.” --Al Pacino

Consider the ant. While pound-for-pound one of the strongest animals out there, since it weighs in at a stunning 0.0003 grams, that metric is less than useful. No, the greatest strength of the ant lies in a colony’s sheer number of ants and the fact that they can act with a single-minded determination to get a task done. Very little short of poisoning the lot of them interrupts their task once they begin and they have the ability for hundreds, if not thousands, act as if one being.

Consider the tiger. Tigers are not pack animals. Add a second tiger to a tiger’s territory and you’ll likely end up with a dead tiger. They do not like competition. And yet, as hunters go tigers are frighteningly effective. They can get to be 4 meters long (13 feet), weigh 600 kg (1300 lbs), can run at about 90 kph (55 mph) nearly silently, and are powerful enough to bring down a rhino or an elephant. Where the tiger walks, things that don’t want to be lunch best move carefully.

Two remarkably effective animals. One that can only follow orders, but carries out its task with a determination and undeterrence rarely found in nature.  The other nearly unable to work with others of its kind, but with a frightening level of individual ability. Both achieve their goals but in opposite, and incompatible, ways.

Despite having just called the two “incompatible”, a development team must be a colony of tigers. Considering the dev lead as the colony “queen”, each developer must be able to accept their marching orders and complete their assignments with the level of determination of an ant. Yet they must not be the mindless workers that ant embody. They must have the individuality of a tiger and a tiger’s ability to successfully determine how to achieve a goal and then the ability to actually achieve it. And the “Colony Queen”, i.e. Dev Lead, needs to understand that the tiger is not a mindless implementer of tasks and if treated as such then the overall effort is endangered.

We all know developers that are like the ant. Practically useless on their own because they can’t hold an application in their head or understand how various objects should relate or even how various pieces of functionality impact each other. But hand them a task and they complete it. We all know developers that are like the tiger. Highly skilled, able to intuitively understand the task at hand and how best to implement it. But get in his way, critique his code, touch his check ins, or even talk to him when he’s in the middle of something and he’s going to bite.

As a developer it is critical to your career development to embody the strengths of both the tiger and the ant while taking on none of their weaknesses. You must be a colony member that hits his tasks reliably. You must be a tiger that can rely on your own skill and experience. However, when your ability and understanding seems to conflict with your direction, you must be able to do something that neither ant nor tiger can do. You must be able to communicate your results and opinions to team leadership, do so clearly and helpfully, and understand that your ideas will not always be taken.

Make no mistake. This is the difference between a successful software developer and one that is perpetually wondering why he can’t keep a job. It’s not ability. Every developer I've ever worked with is either a tiger or an ant. The successful ones are the developers that can maintain those strengths without succumbing to the weaknesses. Are you an ant? Don’t become so focused on carrying out tasks that you forget that you can contribute your knowledge and experience. Not just repository check ins. Are you a tiger? Remember that at some point, you’re going to be overruled. Learn why, rather than biting. Is there a non-functional limitation, such as time frame or lack of stakeholder buy-in, that simple cannot be controlled? Is your preferred path incompatible with another development team’s work? Remember that setbacks are learning opportunities and treat them with grace. Remember also that others have skill and experience as well and respect that. Especially if you disagree with them.

Neither the tiger nor the ant will ever be anything more than what they are. Their weaknesses insure that they are only useful in narrow circumstances. Take on the strengths of both and the weaknesses of neither and you will quickly find that your organization find more and more situations where you are considered useful, or even necessary.