Most of your problems are not technical, they're organizational or cultural. This is not to say technical problems are easy to solve, just that they're solvable; organizational and cultural problems aren't, at least by you.
Organizational culture does not preserve history, it reflects history. People behave as they do because they have been taught to do so. There is likely no more specific reason recorded, as organizations rarely value their own history enough to preserve it. This applies to your users, your coworkers, your management, and you.
There is a significant difference between "is it possible," "is it allowed," and "is it a good idea." Also, sometimes one is caught between "can't" and "have to."
Don't mistake stability for stagnation, activity for progress, or change for innovation.
Certainly you can implement a solution to a given problem with technology A. B through Z, too.
Consciously or not, all applications are built around the current chargeback algorithm. Cost optimizations look less and less clever as the algorithm changes. A feature of the algorithm may be that you are unaware of its existence.
When performing maintenance, never presume the existing application actually works.
Rewriting an application in a different language or framework is only justifiable as elimination of technical debt. Don't mistake this for maintenance, which is an entirely different activity. And certainly don't rewrite just because the code base is "so last year." Personal prejudices and preferences make determining which is proposed difficult.
An understanding of "how it works" is much more valuable than the knowledge of how to fix a subset of the infinite number of specific issues.
Accumulating technical debt is easy, just value one cookie today over two cookies tomorrow.
Naming conventions and shop standards are not natural laws.
Sometimes the greatest barriers to success are our own procedures.
In IT we try to explain with analogies. Certainly there are bad analogies, but even a good analogy is flawed. Pointing out the flaws in a good analogy when someone is trying to explain a concept to you is really irritating and gives the impression you are no longer interested in understanding the concept.
Just about everyone knows the first question to ask when software breaks: What changed? Unfortunately, just about everyone seems to think that's the only question that needs asking. For starters: What didn't change that should have?
All system development methodologies are just terminology plus recategorizations of existing work activities plus graphical notation.
Conan the Developer: To defeat the compile time errors, see the run time exceptions driven before you, and hear the lamentations of the bugs as they are maintained out of existence.
Humans find it distressing not to be in control. Users want to be Developers. Developers want to be DBAs. DBAs want to be SysAdmins. Everyone wants to be more in control of their work environment. Eventually people might learn that that other job, the one they wish they had, that job consists of quite a bit more than just the part they see. IT jobs are like icebergs that way. This also works in the other direction, e.g. SysAdmins who have never been Developers tend to be surprised at all that is involved in a Developer's job.
No user interface design survives contact with an actual user.
Upon fixing a production problem, the next step is to ensure it never happens again.
If there is a system, it will be gamed.
Teach them Assembler and memory management, so their children may learn C and data structures, and their children may study objects and exception handling, so their children may create digital music and art.
"Dilbert" is a documentary about the private sector.
Neither a pure centralization nor pure decentralization of IT development support tasks seems to work very well. I have no theoretical basis for this, I merely note that, faced with either, pragmatism gives rise to a hybrid approach over time.
Making the right way the easy way helps immunize you against having to invent a large number of unenforceable rules. No one is trying to implement an unreliable and unmaintainable ball of mud, they are trying to get to implementation by the shortest route possible. So use that fact to make everyone's life easier.
Many people confuse being cynical with being jaded. The latter comes from years of experience, the former is adopted in an attempt to appear older and wiser. And neither is terribly helpful in a problem solving context.
While "If you build it, they will come" is not a certainty, "If you don't build it, they won't come" is.
Edge cases, invalid input, pathological input, try hard to make your code fail. Certainly someone else will.
You must test whatever you plan to implement, including your implementation plan.
How the work gets done is significantly less important than that it gets done. Methodology mavens would have you believe the reverse.
Talent cannot be taught.
Implementation's just another word for nothin' left to code.
Whether the communication protocol is synchronous or asynchronous, someone will need it to be the other.
Just because something is possible doesn't mean those responsible for its implementation will ever stop whingeing about it.
Don't lose sight of the scarce resource for which you are optimizing.
This is the way it’s always been, therefore this is the way it always will be: in IT this is a foolish conclusion from a foolish premise. “Always” is a word best used with caution. Ask a Geologist or an Archaeologist, and then recall the term “Internet years.”
When all available options are bad, back up and reevaluate the decisions that brought you down this path. Long term, things are supposed to get easier, not more difficult.
Doing nothing has a cost. If nothing else, the cost might be measured in technical debt.
To be good at IT is to be both archaeologist and alchemist, coder and conjurer, engineer and enchanter. IT isn't magic, but the talented practitioner makes it appear so, much like any other creative endeavor.
Standardize and automate.
Stick around long enough and you'll be both supremely and uniquely qualified to do your own job -- and no other.
Just because something works doesn't mean it works well. Implementing the first thing you get to work is probably not a good idea.
Application development seems to have devolved into the artifice of mercilessly stitching together tools and libraries into frankenmodules to be tortured into a lurching semblance of functionality.
For many years the non-mainframe platforms attempted to achieve mainframe performance and reliability. Now that they've got a mechanism to approach that (VMs and containers and clusters and lots of staff to manage them) they'd like applications on the mainframe platform to achieve the rate of change of applications on non-mainframe platforms. Because rate of change is a measure of success, I guess.
Taking into account how things came to be this way is a prerequisite to making things how they ought to be.
Flexibility begets complexity.
Telling a support person that some random page on the Internet said you could do it this way is unlikely to garner sympathy for your position.
Will no one rid me of these turbulent programmers?
Programming has as much to do with typing as surgery has to do with making incisions.
People who want to hold an indeterminate number of meetings to discuss the process by which they will develop the process to develop the policy which will govern future process development are not welcome to breathe the same air as me.
Do not speak to me of eliminating technical debt "as maintenance occurs" -- it is to laugh. The most common tactic for eliminating technical debt is wishful thinking.
Whatever the problem, there are people who benefit from its existence and therefore don't want it solved.
IT Management's greatest trick was convincing itself that assembly line techniques are appropriate in all cases.
Give people clear, accurate, and complete information in the proper context and let them make a decision. Rhetoric is the tool of those who fear the truth.
I have been largely unsuccessful in life, relying on facts to speak for themselves and reason to guide those in power. It turns out those entrusted with decision-making merely seek justification for their personal biases. And yet, I rant.
Those of us who fixed Y2K by rolling up the sleeves on our tucked-in dress shirts are unimpressed by your Six-Sigma "black belt."
Most IT management can't tell the difference between good and good enough.
legacy: of technology, a pejorative term indicating that which one's control over and/or knowledge of is insufficient to one's career goals.
Regarding any code you didn't develop as a black box unworthy of your understanding is not a demonstration of your enlightened status. While no one can know everything, you must always strive to know more. There is a balance to be achieved and it does not lie at simply giving up when the black box doesn't behave as you wish.
accountability: of software development, the process by which TPTB claim credit for success and assign blame to underlings for failure.
At some point layers of abstraction become layers of distraction and cease to be of any use.
I have lost the ability to discern the difference between the unreasonable person who causes progress and the unreasonable person who simply wants everything to be all about them.
Security is hard. Data integrity is hard. Compliance is hard. Maintenance, ownership, and governance are necessary. There seems to be a misconception that the bottleneck in application development is a lack of bodies to do the work, and that any body will do.
Worship of the maverick, the iconoclast, is misplaced. It is not praiseworthy to go against the crowd for the sake of going against. If the crowd is wrong, certainly go your own way, but consider that the crowd is not wrong simply because it is a crowd.
IT shops must encompass the skill sets to indefinitely drag the baggage of applications developed for what previous generations thought was to be the one and only platform, each with its own quirks and foibles, never actually migrating to a single underpinning, forever dealing with integrations reliant on tenuous agreements and bits of string.
It grieves me that the tools with which the world was built are being discarded due to fashion.
Edge cases are hard. But that's why you get paid the big bucks.
The best case scenario for preventive maintenance is that it will seem a waste of time. This is true for computer systems, automobiles, and pretty much everything else.
Perception is nine tenths of the law.
With ability comes responsibility.
It's not a good idea, it's just allowed.
I follow a rigorous software development process; You are subject to a bureaucratic nightmare.
The unexamined application portfolio is not worth maintaining.
A lesson I never learned: Don't attempt to disabuse those in power of their cherished misconceptions.
You get what you pay for. As employers seek to hire developers for the lowest compensation rate, most software development is thus produced on what is essentially a low-bid basis. Pride in craftsmanship is the only thing saving us.
I find "It isn't illegal" a feeble excuse to treat the employees badly. It also isn't illegal to treat them decently.
The perfect may be the enemy of the good enough, but that doesn't justify delivering a steaming pile of unmaintainable pasta cobbled from various dodgy websites. Code does not become "good enough" when you're tired of working on it.