Career Advice from a Neo-generalist Perspective.

Compass StudyPeople ask me career advice now and then. Generally, people who do so can’t follow the beaten path.

There’s plenty of career advice out there for the beaten paths. The basic recipe is simple:

  • Secondary School
  • Tertiary Education
  • Maybe specialize further.
  • ?????
  • Profit!

I’ve met a few people who this has worked for – which means going in debt with student loans sometimes, or having a tether to parents paying for things, or what have you.

The last part, ‘Profit’, is delayed until after people are repaid – bad news, parents are never repaid. In the context of the United States, which is hardly a data model for the rest of the world (but my experience), we have the rising cost of not continuing one’s education versus the toll of student debt.  The fact that studies are largely done by people who followed the beaten path further confuses the issue at times.

How often do you hear a college say you don’t need to go to college? Of course they wouldn’t say that – and one could say that the student loan issue in the United States is akin to tossing out mortgages to people who can’t afford to pay the mortgages. It’s all very muddy water, and where once I had an opinion I just see a sea of biased data and biased opinions and have none myself.

My Path.

My life, my work history, my education – they don’t fit the accepted model of education, ???, profit. I grew up working through secondary school in a printery, in a electrical motor rewinding workshop, and whatever odd jobs came my way. Despite this, and I would later learn because of a former Irish brother who had married a nun, I did not get expelled and managed to graduate – well.

My parents didn’t put me through college, and the debt I did incur toward not finishing college in the late 80s is something I paid off about 22 years later. The interest was bad, but I managed to settle with the Department of Education for pennies on the dollar. Incidentally, despite being what one might term a minority, I wasn’t African or Hispanic enough to gobble up any grants specifically for those minorities. Equal opportunity ain’t so equal.

My time in the Navy was so busy that I never seemed to have time for college classes or college credits. It’s hard to study full time in NNPS and work on college credits at the same time, or work in emergency medicine and pop off whenever you needed to; when people’s lives are at stake you don’t have that luxury. And getting yourself together after being discharged while attempting to support an ill parent just didn’t leave much room for college, or debt – or paying a debt which I still owed, and thus couldn’t continue college. A nasty trap, that, even with the military deferment.

And so I found myself back behind a computer again through some luck, working at Honeywell and proving my worth. It was a cool job, and I had convinced my manager to give me a book allowance where I read the most bleeding edge stuff I could find back then. It was awesome, if only for a while. Others, like Dr. VcG, tried to help round me out and did so a bit, but really, I was focused on just…. learning.d,

I was told that they would pay for my classes to finish a degree so that they could promote me, which I then began – oceanography – and I was to find out that they wouldn’t pay for classes toward that end. No, they wanted me to get a degree in something they were already paying me to do. Why on Earth would I need a validation for them to be promoted when I was already validating it every day at work?

There was only so much I could learn there, and changes to the company started taking the ‘play’ out of it all.

I moved from this company to that, building up references, building up experience, but most importantly to me, knowledge. My knowledge wasn’t validated by some group of academics, it came from the Real World. As time progressed, the economy went down as my age went up, and I found myself working for money instead of knowledge. It was not fun anymore, and I moved on… to where I am now, with a few interesting stops on the way.

Serial Specialist, the Neo-Generalist.

The beauty of software engineering when I started out is that once you could get a computer to do what someone else wanted to do, you got to learn about what they wanted to do. I got to learn about business, banking, avionics, emergency communications, data analysis, science, robotics, and so much more – and I have this knowledge, hard won, without following the beaten path and getting a bunch of letters behind my name.

It’s where all that knowledge intersects that the cool and fun stuff happens. The beaten path could not have given me that.

Frankly, in my experience, the beaten path is pretty slow – which some say is a reflection of my ability. I don’t know that is true. What I do know is that the real world, paying bills and keeping abreast of responsibilities required me to learn faster than I could get a formal education, and I did. Simply put, I had to. I loved most of it, I hated parts of it.

Career Advice

When it comes to the beaten path that I did not take, I point at it. It works for a lot of people, though the ‘works’ does seem increasingly dubious to me as far as a return on investment. Go study something if you have the opportunity or if you can create the opportunity. Get your education validated, but don’t stop learning.

You see, what I can tell you with a degree of certainty is that the world is as bad as it is because of those who rest on their laurels after getting a certificate or a degree. I can also tell you with certainty that the world is as good as it is because of the people who keep learning and applying that knowledge toward good ends.

We don’t need people who are ‘educated’. We have enough of those clogging up the system. We need more of those that are constantly learning, certificate or degree or not – those are the ones who create true progress. Speaking for myself, I pace myself to 2 books a week or more on topics that range widely.

The world is interesting in many ways. You can make it more interesting by knowing how interesting it is from different perspectives.

Learn how to negotiate. Get as much as you can even though you don’t need it – a problem I had – because you don’t know when you will need it.

And avoid working for idiots if you can. You won’t be able to, and sometimes it’s not obvious until later on, but ditch them as soon as you can.


The Study Of What Others Do.

Taran Rampersad
Courtesy Mark Lyndersay, LyndersayDigital

I hate having my picture taken. Over the years, I have found the best defense from cameras is to hold one. This has weakened in a day and age where every phone has a camera, and everyone wants to be seen with someone – but Mark Lyndersay needed a picture of me for TechNewsTT, where the majority of my writing has been published this year outside of my own websites.

In going to his studio, it was a rare glimpse for me into the world of professional photography. It was clear to me almost immediately, this amateur photographer, that it would take me at least a decade to do the editing I watched Mark do quickly, about how he managed his photos, and about why he did the things he did  – a matter of simple experience that cannot be replaced with meetings and requirements discovery.

You see, I had been thinking of writing my own photo management software in Python – something to automate a lot of things. I had briefly considered this when I had begun selling some of my prints in Florida, and it was latent in my mind as a project to ‘get to’. In conversation with Sarita Rampersad, another professional photographer (unrelated), I had asked her what she used last year and why. It was clear that it would take more than a passing effort on my part to build something more useful than the tools she was using. The visit to Mark’s studio underlined this.

The Roots.

Reflecting on this on the way home, I went back to the very core of how I started working with technology. From an early age, I was encouraged – by rote and by whip, as it were – to observe what was being done to understand how it was being done. This was the root of the family business, the now gone Rampersad’s Electrical Engineering, a company that was built on fixing industrial electro-mechanical equipment with clients ranging from the U.S. Navy to someone who just needed their water pump repaired (Even WASA).

This background served me well over the years, and understandably frustrated managers and CEOs. Knowing the context of how things were used allowed for for useful processes and code; it allowed for things to become more efficient and allowed things to be written to last instead of a constant evolution of, “Wouldn’t it be nice if?”. In a world of agile processes, the closest thing to this is the DevOps iteration of Agile which even people who practice Agile haven’t heard of (because they are soundly in the Agile Cave).

DevOps is a form of Agile where every stakeholder is directly involved. And that, to me, is also a problem because of the implicit hierarchies and office (if only office) politics is involved. It’s a bleeding mess of tissue to sew together to form a frankensystem, but at least that frankensystem is closer to what people actually need. Assuming, of course, they understand what they need.

To me, it boils down to studying what other people do.

Observe, Analyze, Communicate, Build.

When I started as an ‘apprentice’ programmer, this was drilled into me by an Uncle who was a Systems Analyst, and ‘allowed’ me to write the code for projects that he was working on. He didn’t boil it down to observe, analyze, communicate and build; I refined that myself over the course of the years.

No matter the process, it all boils down to someone able to bridge how people work/play to get something done to understand what is needed, and how to make their lives easier through automation and information structure. Observing people do their jobs is important, analyzing it secondary, but the most important part is the one thing that an AI cannot yet do: Communicate, the process of listening, speaking (or writing, or…), and then feedback. This process is most important. In priority of importance, software engineering and I believe any form of process or structural engineering is:

  1. Communication
  2. Observation
  3. Analysis
  4. Build

This is not the order in which things are done, of course, but the emphasis that is most important in understanding how present systems work and how future systems should work.

So often over the years, I’ve seen software engineers relegated to the role of code monkeys with emphasis only on ‘Build’, when the most important parts are about ‘building what is needed’. This is where business analysts got introduced somewhere along the way, but they too are put into silos. This is underlined by HR departments focusing only on the ability to ‘build’, where analysts are expected to be a different sort of role. When these roles were split, I cannot say, but to be both is something that is too large and round to fit in small square holes of the modern enterprise.

It is lost, eroded, and there is a part of me that wonders if this is a good thing. Studying what other people do has allowed me to do so many things within and without technology, and it worries me that in a future where AI will be taking over the ‘Build’ that software engineers aren’t being required to focus more on the soft skills that they will need in the coming years.

Sure, the AI can build it – but is ‘it’ what needs to be built?


Image used with permission of photographer, Flickr user cea. Click for original.

I don’t miss it.

There was a time that it didn’t seem like I ever could. It was all I did. Coding, designing, architecting, playing with new languages and frameworks – it was great. I spent hours upon hours getting good at things that were, in the end, just passing fads.

Passing fads with ‘benefits’, really. The ‘benefit’ being the ability to find work maintaining someone else’s crappy code. Maintenance.

No one looks forward to a career in software engineering maintenance.

But that’s the majority of the industry, and if you’re good at maintenance, they’ll pick someone else to do the new development no matter your experience level. They need you there with your finger in the dyke as you watch them do it all over again – making similar mistakes.

No, I don’t miss it.


I don’t miss sitting in meetings to watch other people beat their chests and claim credit for things that they didn’t do as political necessity. I don’t miss reading emails written by people more interested in trying to impress each other rather than actually communicate what they need to.

I don’t miss being told I should be at my desk more often when I was one of the few people meeting deadlines, milestones, yardsticks and tombstones. I don’t miss the tiresome code-jockeys who don’t know a thing about process and were graced with writing them. I don’t miss going through undocumented code and figuring things out to rewrite a new iteration that will never be used. Oh, and if you were ever on call…

There’s really a lot not to miss.

And as software engineering goes, that’s pretty much the way it is. That’s a pretty average career, since most work in software engineering is maintenance – and maintenance, after a certain period, shows you everything that was done wrong. But since you’re doing maintenance, you don’t ever get to use it at work. Maybe you do it at home, but honestly, after a few decades you may not want to stare at a computer when you get home.

No, I’m playing these days. I finally got back to why I started it all in the first place.

Except I have a lot more experience. And I can walk away from my desk, I can eat what I want when I want, I can wear what I want…

Cubicles? Offices? That’s for managers.

Identifying The End of the SDLC (2015)

Killer QueenDeath is not the opposite of life, but a part of it.Haruki Murakami

Software projects die. Call it retirement, ‘end’, whatever you wish – they die. In a perfect world, this is planned for – expected – understood. In the real world, many software projects were never established formally and have to be brought, kicking and screaming, to the table for hard decisions to be made.

Some software projects continue living out of some perverse masochistic need to keep them living – but they’re dead but for the efforts of those keeping them alive. Sometimes it’s necessary to admit that the software is beyond repair if only for a business to stop losing money and by that time a company is already deep in the quagmire in the project.

This, of course, is written mainly for businesses with software projects. Some are defined as software projects and some are not – I’ve encountered quite a few software projects over the decades that started off with the question, “Wouldn’t it be nice, if?”, and evolved based on that – a spiral model of requirements that doesn’t necessarily translate into a spiral model of development. While I have worked on successful projects and the world celebrates such successes, it’s the failures that create best practices and other rules of things-not-to-do.

A best practice should be planning for the end of the software life cycle throughout the life of a project – including planning the project. That’s part of any solid software development plan – a living document of a project. that exists in one form of another, be it in one person’s head or many people’s head. The latter creates the conflicts in a project that putting the document in written form so necessary. If this development plan doesn’t exist, identifying the end of the software project – it’s death – is almost impossible.

There are a lot of my fellow professionals out there who know about the software development life cycle to varying degrees of intimacy. In theory, we all want to begin things properly but we never discuss the end too much – and, oddly, the end is typically what employs the most software developers outside of relatively few software companies – the fact that when the software project was started no one planned for planning for it’s death. “Just one more change”, someone will say in consternation, “and we’ll move on to the next evolution because…. <insert your phrase of choice here>“.

It’s rarely blatant to management, and depending on what motivates the software developers, they may be immune to the pungent smell of necrosis if only for fear of not finding employment in a job market that is less than friendly.

For any technology to be sustainable, the economy surrounding it must be sustainable. Identifying the end of a software project requires attention to new technology adaptation both inside and outside of the user demographic as well as an actual interest in what the user demographic wants (will pay for) and needs (what it cannot do without).

The key to knowing when a project is dead is assessing whether the project will make more money than is being spent on it. I’ve worked on projects decades old that were still quite profitable and I’ve worked on projects a year old that were money pits – and a business that keeps throwing money into the money pit is unlikely to remain in business longer than their capital permits.

So how can you tell whether a software project is necrotic? There are a lot of very subjective things that have to be considered, such as the business direction and vision of the future as glimpsed by management – and they color the items listed below as well. In the end, it’s up to management.

There are also very, very simple things that will tell you whether it’s time to break out the candles for the project and will help assess whether any software project is in it’s death throes – or toxicly necrotic for the business.

  • Spending More On The Project Than It Brings In: While this is true of most startup software, the subjective aspects of vision and business direction overshadow it – and sometimes they continue to do so longer than they should. A software project should have a budget. Your company can fight over what is considered an expense and what is considered revenue (it’s not always cut and dry), but if you’re paying software developers more than the project is bringing in, someone should begin asking questions. Startups might be considered exempt but they shouldn’t be – at every iteration, this has to be looked at and with startups even more so than mature projects. Why? A misstep could be the end of it all.
  • Underlying Technologies Are No Longer Competitive/Supported: If you’re required to run a project under DOS or CPM, it may be time to pull the plug. If there’s a niche market, that’s nice. Just make sure that the niche market is paying your overhead and profit. Another example might be a lot of code that is not compliant with the latest and greatest strides in the language. I’ve seen PHP 4 code stuck on LAMP servers that belong in museums – running live on the Internet, where script kiddies are more than happy to show the willing that it’s time to move on with their probing.
  • The User Demographic Says So: Users are a peculiar group of people who don’t necessarily write long and detailed emails about what you’re doing wrong for them – in a world full of software options, it’s hubris to think that your company is so special that your users should invest themselves in your product. Social media makes getting feedback easier but tweets like, “your product sucks” just don’t give the granularity necessary to steer the project.

There are no silver bullets in here. Everything has to be considered within the context of the business and the key problem is that there’s a level of introspection required that wouldn’t have allowed the software project to get where it is now. It can be an uphill battle with those who make decisions since they may have seen how much they invested in the technology in the past as some form of wedding ring.

Image at top courtesy Louise Docker, who made the image available under this Creative Commons License.

The Human Factor: Tangible Results

Mas allá de lo tangibleOne of the issues I faced across the decades of my professional and private technology endeavors has been, simply put, the amount of intangible there was.

A visit from my father in the late 1990s saw him proud of what I was accomplishing, but he had really little idea of what I was doing. He was of the electro-mechanical engineering sphere, a meshing of the arcane art of visualizing the magnetic fields of motors and the results that they churned out, physically. He enjoyed the recliner, the space in my apartment, and the ability to watch a flat screen in any room he was in – he appreciated the rewards of my work but not the work itself. Later, when he saw me strip myself of those ‘rewards’, he had no idea what I was doing even when I was getting media attention.

The human factor of sharing any achievements is difficult enough given the shifting sands of technology and the ability to comprehend them to understand the achievements. Dealing with things covered with Non-disclosure agreements, non-compete agreements, trade secrets and so forth creates a divide between people one doesn’t work with – sometimes unbridgeable. The idea of being the keeper of secrets is a romantic notion when it can be pretty tragic. I know I lost a few girlfriends to my being lost in thought about something that we could not communicate about. Call it a personality flaw. Mine. I live what I’m doing and employers and businesses loved me for it.

And then there’s the disconnect within a business, where the tangible results are misted by horrid implementations of the Agile processes. It’s why I prefer a more DevOps methodology. In the latter, there are tangible results with Operations, who are part of the process.

There is no complaint in any of that, simply a statement of fact. I bring this up because in comparing my battling the Trinidad Roseau versus Software Cost Estimation.  On one hand, I have tangible results that I can write about and share with others, and on the other hand I am writing about how developers can’t properly estimate given the effective silos in a company that keep them from being a true part of the larger project. This is where startups are awesome to work with.

Everyone has a balance. Some people can balance these things better than I can, some people cannot balance them at all – at points, I balanced them well – but life isn’t a sprint, it’s a marathon.

But I do think that Software Engineers and others in Information Technology deserve more in the way of expressing tangible results not just to others, but for themselves.

On Software Cost Estimation

University of Maryland and Sourcefire Announce New Cybersecurity PartnershipA recent video had me considering the problems of software engineering cost estimation – something that has plagued software engineering. It has also plagued people who think software engineering is just coding because, frankly, they’re idiots.

Since I’m out of the industry – by my choice and on my terms – I can now tackle some topics and speak my mind more freely without worry of repercussions when it comes to the next contract, or the next job.

The video is, “How To Price Design Services“, and I’ll embed it at the end of this post.

Now, when it comes to software cost estimation, we start off by gathering requirements. We come up with a design, or alternative designs, built on architectures and technologies that may be new or not, that a company might have the resources to do or not, etc. Some people call this ‘discovery’. Based on what is found in discovery, an estimate is done by reading tea leaves, a magic 8 ball, estimates of coders, and perhaps killing a gluten-free chicken and reading it’s entrails. That’s about as scientific as most people do it.

And how does one get the estimates? As a software engineer over the decades, I know an estimate given by someone writing code (not necessarily a software engineer) is:

  • based on assumptions based on the documented or communicated (mistake 1) information that leads to assumptions (mistake 2).
  • based on their skill level and experience, as well as innate ability.
  • dependent on how much pressure is applied to them, with different thresholds for different individuals.
  • usually wrong.
  • never tied to the value for the company.

Now, I’m not saying that the value of a project for the company should be the estimate – far from it, that’s just not how business works. But let’s talk about profitability – immediate and recurring.

The immediate profit usually doesn’t work out unless a marketing department is brilliant, or there is a monopoly, or both. So it’s about recurring profit. How much would be expected as a return withing – oh, let’s say – 6 months?

The point is that there is a value associated with the project that is rarely communicated to the development team, which is usually – hopefully – smart enough to pick this apart. And the people asking for the project almost never want to let the development team know the value that they’re contributing because those salaried employees will want more money.

Meanwhile, every software project encounters problems because of technology changes, changes on the development team (a problem of poor hiring or poor retention policy), requirements creep (‘someone in the sales department just had a great idea!’), design flaws (they happen), architecture problems and…. well, just about everything.

The main problem with all of this is that estimates simply aren’t accurate – which, actually, is exactly what they are supposed to be. An estimate is never accurate. It approximates, and people don’t get fired too often off of teams because of their coding abilities, but because of their or someone else’s estimation abilities.

There is a point here. That point is that the development team is only as invested in the project as the business team and management permits them to be – and if they’re better invested… productivity will increase and there will also be more careful and thoughtful estimates.

Now, does ‘invested’ mean ‘more money’? Sometimes. Free gummi bears and a gym might work in Silicon Valley, but they also make a metric buttload more money than a development team in – oh, let’s say Orlando, Florida. No, that ‘incentive’ is to get people to stay physically in place in a brick and mortar establishment which, sadly, is still the norm. But they don’t actually make people tweak that bit of code just a little more efficiently. You don’t toss gummi worms at developers and they prance around.

It’s about being vested. And that’s the core problem of cost estimation – the developers are given a black box to fill with little to no actual information from the business.

Oh. That video:

The Coding Precarity

Decoding Alan TuringThere’s a brave new world coming, and it’s something I’ve been considering for the past few years. As artificial intelligence begins writing more and more code, and troubleshooting it, the women and men who have made their money speaking to machines are slowly joining the precariat.

It’s not a bad thing or a good thing. It’s not a matter of the sky falling. It’s a simple reality that the precariat needs to consider and find a way past.

Coding is a part of the Software Engineering discipline – wherever it actually exists as a discipline. Coding, on the other hand, is not the entirety of Software Engineering despite what the market appears to think.

HR departments all over the world are trying to fill what are really glorified code monkey positions. And that’s not the future of Software Engineering as I see it, or as circumspection will show. We’re seeing more and more code generated by AIs, and really, if you actually

It’s going to be about ‘soft skills‘. It’s going to be about getting the right requirements to hand off to the coders, because the coders in time are less and less likely  to be human. It’s going to be about interacting with the people in dealing with what they want and making sure that they get what they want.

Of course, wanting what they actually need is something that they still need to get better at. 


On Quality In Production Code (2012)

So I’ve been playing StarCraft II: Heart of the Swarm

Once upon a time in a universe resembling this one at a younger stage, I dreamt of game programming. I don’t think that there’s any coder of my generation that didn’t have similar aspirations – perhaps getting published in Compute! magazine, perhaps getting one’s name on the box, or maybe even just writing a really cool game. I stand with the majority of developers who have never done that sort of thing. Times changed.

Consider what the person who wrote Galactic Adventures and Galactic Gladiators had written on the Well (apparently before they thought of putting a name to it):

To me, the most amazing thing about doing these games (and I’m about to date myself) is that I did virtually everything myself. I designed the games, programmed them, drew the graphics (quite primitive), wrote the rule book I did get help from friends and people at SSI in testing and making suggestions. Compare that with today where new games are developed with a million dollar budget and use teams of 30 or more people, programmers, artists, tests, story consultants, etc, etc. And you know what — the games of today are better (Gee, why is that a surprise?)

With that in mind and considering that I knew about Blizzard when the original Warcraft was a freeware game where you paid a bit more to get a full version – no, not the MMORPG you kids play now, but the Warcraft that started a new genre that Starcraft continues – Blizzard has come a long way. Since then, Battle.Net has come online. Since then, numerous titles have come through Blizzard and, while I haven’t played Diablo or messed with World of Warcraft, not one title hasn’t been popular. Blizzard has a kind of magic that works for them. I just like a particular genre and have found MMORPGs to be disappointments when it comes to content; I dislike leveling a character by what is properly termed grinding.

All of that said, I’m sure the budget for the Heart of the Swarm expansion was over a million dollars. I’d wager that it was at least 10 times that amount. The detail is great, the storyline is good (though how a prisoner in a high security prison has a pistol escapes me) and it’s playworthy – though I keep mixing up Q and A on the keyboard. But here’s the thing: I played through the game that took so long to develop in about 8 hours of game time. Hard difficulty, much the same. Brutal – well, that’s still in progress. There’s always the PvP maps and the challenge maps. I figure that, all things considered, the game will last me well over 1,000 hours of playtime.

It sold 1.1 million copies in 48 hours. At $40 per expansion, that’s $40.4 million in 48 hours.

Yeah, we’ve come a long way from typing in games from magazines. We’ve come a long way from a single developer writing a game. There was a magic to that era, though – we didn’t yet expect a great game. We expected a game and hoped it would be good. Now people get their sodden underwear twisted when they start talking about game balance and other things on the forums. As a fuddy-duddy, I see that as an odd form of entitlement – people expect a lot more for $40 and have the privilege of time to gripe about it in poor writing.

Game development has come a long way. Humanity? Not so much.

Thank you, Blizzard, for what I consider to be another great game. As a developer, I wish I had a hand in it. I’ll wait for the Protoss section. Take your time.

Code Responsibly (2015)

Control YourselfWe are stuck with technology when what we really want is just stuff that works.

Douglas Adams, The Salmon of Doubt

More often than not I’ve had to deal with projects where I sincerely wondered whether salespeople and upper management – those that charge admission for the voyeuristic tendencies of the public in relation to technology – understood the implications of decisions. Examples abound. Planned obsolescence of a business infrastructure based on a technology tree. Coding one’s business into a corner. Complaining about the spaghetti code but forcing the conditions where all programmers can do to keep their jobs is make meatballs (features) and slathering the thing in sauce so as to keep those that sign paychecks appeased with something… resembling… something palatable. The list goes on.

Somewhere in the 1990s, Free Software and Open Source came along and put programmers in charge of much of the business process. Because of experiences I’ve had over the years, it was easy to say, “hey, this might fix everything!” Years of experience, though, made me bite my tongue because… well, because programmers are mostly interested in writing code. It’s rare to find a programmer that is interested in actually creating a product. Just as there are no unfinished poems for poets, there are no unfinished programs for programmers.

This has haunted Linux. Granted, Linux at its core has a benevolent dictator that keeps feature creep and feature tsunamis under control – but the desktop Linux never took root as much as it could have because software developers aren’t as good at keeping things simple. Frankly, in general, we suck at it. It’s not a bad thing. It’s not a good thing. It’s the way it is. There are outliers, of course, but those are rare. I’m one of them and it’s because of something quite simple I learned as a Navy Corpsman:

First, do no harm.

Harm is a subjective term. There are even people who appreciate the common understanding of the word as pleasure though this is a family friendly blog and we won’t discuss that much. Let us say that, generally speaking, there are almost no people on the planet who would wish to have harm propagated against themselves. Yet software developers have a tendency to do it every day. I’ve done it and, on much rarer occasions, I can catch myself doing such things because I’ve learned to identify them.

That’s why I really enjoyed Paula Rosenblum’s article, ‘Is Software Quality Going To Hell In A Handbasket?:

…Can anyone yet understand why the MS Office interface has changed completely twice in the last three releases? How many hours of productivity have you lost hunting for menu items that you knew by heart last time around? And do we even want to start talking about Windows?  Not today. These posts are only supposed to be so long.  Let’s just say when your Executive VP banker brother-in-law calls to ask you how to print a document in Windows 8 you know things have just gone silly…

Paula completely nails it, and that’s just a piece of the article.

Simplicity is really the key. Yet simplicity isn’t that easy when expectations are constantly evolving. The only way to actually assure a good balance of features and meeting user expectations is something that most software developers suck at: Communicating with users.

It’s almost akin to having Marines who were naughty getting stuck with KP duty – where they cook for other Marines. The Marines don’t see a flaw in this logic.

To make matters worse, businesses are also not that great with the balance – and in being bad about the balance, they often spend more money than they would have to in chasing their tails – or as they see it, catching that thing that’s oh-so-close-all-the-time.

Programmers do it to themselves. Businesses do it to themselves. Worse, both can propagate it on others – and often do.

First: Do no harm. Code responsibly. And use the right technology – just because you’ve invested heavily in it doesn’t make it right. The world has been littered with the bodies of those that meant well while reinvesting in bad debts.

After all, the income you save may be your own.

Image at top left courtesy Flickr User JOSE VICENTE JIMENEZ RIBAS through this Creative Commons License. Enhanced by Zemanta

Getting Out of Firefighting Mode (2015)

WildfireIf Prometheus was worthy of the wrath of Heaven for kindling the first fire upon earth, how ought all the Gods honor the men who make it their professional business to put it out? – John Godrey Saxe

Sooner or later any seasoned software developer, programmer or project manager finds themselves in firefighting mode – where it’s a matter of putting out a fire so that it doesn’t spread to other things, taking a project down. Some people think that the ‘fingers in the dyke’ are a more appropriate metaphore – and at times that is true – but I’m writing about firefighting today.

Getting out of firefighting mode is relatively easy. Like fire, there are certain things that are needed to create the conditions for the fire in the first place. A fire needs fuel, oxygen and a source of ignition.

Oxygen is easy in a software project – it’s a requirement for the software project to start and survive in the first place: users.

The fuel, all too often, results from poor software and system administration practices and poor management decisions.

Like fire, the ignition sources can be many. It can be the fuel rubbing together to form the friction (bad decisions culminating into a burst of flame), or a visiting pyromaniac (someone taking advantage of an exploit), or enough oxygen (users) blowing over a hot spot (friction) that causes a burst of flame.

The only way to get out of firefighting mode with a software project is to deal with the cause of the fires. Sure, putting out the fires is important, but sometimes you can’t put them out fast enough – and unless you treat the underlying cause, the fire will gut the project.

Almost all the time, the people who have been fighting the fires have opinions on what is causing all the fires – and they typically have a plan to tackle them, if only they had time or management approval. Despite our best efforts in Hollywood, time travel is not yet viable – and that leaves us with management decisions. Management decisions over a period of time become company culture. A culture that is derisive of good software project management is almost impossible to change unless something drastic happens.

About 15 years ago, I came up with a phrase that seems to be pretty accurate since: Management doesn’t smell the fire until the flames are licking their posteriors. Until they understand that there is a problem that needs to be solved, they will not try to solve it. The time can vary depending on how much attention they are giving to the issues and, where the real problem usually is, how much they trust the people that they hired to talk to warn them about these things.

If you can’t solve the management/leadership problem, you’re sunk. You’re done. Cash in your paychecks and update your resume.

If you can get management to see the need for change – probably with the help of someone in finance who will point out how much money is being spent fighting fires – the only tried and true way to get out of firefighting mode is:

(1) Take a hard look at whether the project is dead or not. If you’re so bogged down in maintenance mode, it’s time to figure out what Plan B is. If not…

(2) Start implementing best practices, from source control to documentation of the project itself. When there are too many things going on, find a finite area to begin controlling and start controlling it. It’s an uphill battle but it can be done with management making the path clear.

(3) Draw lines in the sand. If fires don’t meet certain criteria you set – don’t fix them. This is triage and has to be decided with the overall project in mind.

Image at top courtesy U.S. Fish and Wildlife Service, Southeast Region, and made available under this Creative Commons License.