I guess I'm just lucky (and you certainly can't rule out the possibility that I'm highly blessed and favored of the Lord), but in over a quarter of a century of professional IT software development, I have been on more successful projects than unsuccessful ones.

Full disclosure demands that I admit that some of those projects were declared successful by management despite a complete lack of evidence of any actual success, but as a humble developer on said projects, we would all get tarred with the success brush, so none of us minded that.

Through conversations with co-workers and using my observational skills, I quickly learned that successful projects are few and far between. I suppose you could argue with my definition of successful project, but that's also part of the problem, that there is no widely accepted definition of what constitutes a successful project. Within corporate IT a successful project is generally one that is declared a success by management. When this happens a party is scheduled, everyone gets cake and coffee and if there's anything left in the budget the developers get a t-shirt or a hat.

I have been internally processing this for a while now, with many pieces falling into place over the past couple of years. This week I was mowing my yard and listening to the Jocko Podcast when enough of the remaining pieces fell into place that I am tempted to describe it as an epiphany. I previously had a minor epiphany on the use of the SCRUM development methodology, so these things happen to me now and then.

The Jocko Podcast looks at everything from the perspective of the teams (that's the United States Navy SEAL Teams) because Jocko's a 20 year veteran of that branch of the U.S. Navy. I'll let the military SF (special forces) enthusiasts debate which exact SF groups are the best, but the teams are always a strong contender for the top spot. They have a history of actual, provable success that would make any IT project manager envious. This success comes by design and is built into the way that they do everything that they do, from initial training to their ongoing deployment processes. I would not be surprised if every other SF group does things in a similar way as the teams do, but I know more about the teams because of listening to 197 podcasts (to date) by Jocko, so I'll stick to using them as my military example.

When you join the teams (let's consider BUDS as the interview) you are trained and get to select your preferred specialization. Some want to be the radio guy, others prefer machine guns, others breaching. Whatever you specialize in, you are also trained in all of the core skills that the teams use. At the end of this initial training you are assigned to a team and move to wherever they are based out of. Upon arriving at your assigned team, and after a little hazing, you settle down into an ongoing cycle of workup and deployment. Workups seem to vary, but they seem to be generally around eighteen months and deployments are an average of a year. These numbers are not written in stone, but are good general indicators.

The teams pattern is workups and deployments. The workups are time spent training for the deployments. This is where, based on what they expect their missions to look like, they train to be ready for the role they are likely to be asked to perform. Each workup is customized for it's subsequent deployment. Going to an urban area? Cool, you'll get lots and lots of CQC (Close Quarters Combat) training. Everything that is predicted they will do will be on the training schedule. All training will be done together by the teams to ensure that the individual members of the team are skilled and extensively practiced at working together. Finally after all of their practice, the team is deployed and spends their time in the deployment AO (Area of Operation) conducting missions and doing anything else that is in the best interests of the United States of America and its allies. After the deployment, back for a little R&R (Rest and Recreation) and then begin the next workup.

Now, everything you just read about the teams comes from listening to a podcast by a retired teams officer. I may have a few details slightly off, but it's a good representation of what they do. On the matter of IT project work, I have over quarter of a century of personal experience that I can draw upon. Modern corporate IT does so many things differently from the teams.

The first difference between IT and the teams is that there is precious little training in most companies. Most programmers have only the skills that they knew on the day they arrived and anything they've taught themselves since then. Many of the self-taught skills are new technology studied only as deep as the book that they chose to buy and learn from. Most of the real learning takes place when actually working on a project. The lack of training is driven by the lack of a training budget which is driven by the fact that IT is viewed as a cost center in most corporations. IT exists as infrastructure. There is very little consideration that nothing would get done without IT, so IT while perhaps not a profit center is more than a mere cost center.

The next difference is that there is very little understanding of what a team will be doing in 18 months. The words strategic and programmes get thrown around frequently, but that never seems to translate into managers knowing what their teams will be doing beyond the current quarter. Obviously the business climate is very changeable and long term plans may need changing to reflect events and external factors, but the same is true for the military, so this does not seem like a realistic excuse.

Unlike the teams where everything is oriented around keeping a team together and making them a unified whole, the corporate IT world treats everyone as fungible resources. Every last one of us are replaceable at both the team and the company level. It is the extremely rare team that gets to work together on two projects in a row. Many teams don't make it through half of their current project before members are being swapped in and swapped out on a seemingly arbitrary basis. Team cohesion in most corporate IT departments is risible.

Most of corporate IT has a poor track record of selecting good tools and programming languages and sticking to them. The mainframe side is usually an island of tool and programming language stability, but then the mainframe typically runs COBOL and perhaps three other languages, so the opportunity to go too wild is not an option. The rest of corporate IT is unfortunately a frenetic buzz of different technology stacks. This team uses this language with these libraries and this application server, while that team uses another language and different libraries to access a different database and, of course, a different web server. This seems to be getting worse at an increasingly rapid pace. The young programmers entering the fray love them some JavaScript or Python. The JavaScript folks seem to consider any framework or library older than six months to be dusty and crusty and only suitable for use by old programmers (also known as anyone thirty or older)!

The realistic upshot of all of this is that far too many projects are being worked on by teams that are not cohesive, using technology stacks that are not proven (and may not be around in another 12 months), in which almost none of the team has been formally trained and consequently produce software that can only be described as slapped together, in timeframes that should make management blush with the foolish quickness they demand.

I have worked on projects that have been sold within the company as "bet the company" projects. These projects were so amazingly important that the very survival of the company would depend upon its successful completion. Yet, despite all of the talk of importance, there was no matching effort put forth by the company to position the team to win. No effort to give the team opportunity to form into a cohesive software development powerhouse. No effort to help them select a stable software stack and ensure that they were fully trained in using it skillfully. No suitably sized budget to match such a "do or die" project effort. No highly successful managers with a history of leading successful software projects. No experienced technical leads to provide "at the coalface" support to the development team. Nothing. And the result? Mostly a borderline failure that was declared a success and then quietly patched for months or even years afterwards until it mostly worked like it was originally promised to.

Software development can be done well. NASA have a pretty good history of software that gets probes to the far reaches of our solar system successfully and puts men on the moon and brings them home safely. The telecomm business has achieved incredible levels of uptime and reliability using programming languages like Erlang. There are banking systems that just work, written in COBOL. That said, there are many businesses that treat software development in an unserious fashion and reap the consequences in unreliable and inaccurate systems and burned out programmers.