Write code as if you were not allowed to comment it.
Then break that rule, and write comments.
Write code as if you were not allowed to comment it.
Then break that rule, and write comments.
Communism can work. For a short duration, and with a limited number of like-minded participants, real communism can work (or at least appear to work). In most other cases, communism just doesn’t pan out.
When faced with the long list of failed communist experiments, hardliners will always say “well, that was not real communism”. Which is true. But when you consider the nature of man, there really are just two options “bad communism” or “no communism”. I prefer the latter.
Same goes for Agile.
Observing a jelled team that is firing on all cylinders, you’ll see that dogmatic adherence to “process” is not enforced. That there is a lot of informal communication (on the technical topics), and the tasks are broken down to manageable chunks with a clear scope. The team can quickly adapt to changes in the environment simply because it is agile. Wouldn’t it, then, be nice if we could write down how these guys are doing things, and then apply it to everyone writing software?
Here’s where reality sets in.
Some people are simply not fit to write code, and some people are not fit to write specs.
It doesn’t really matter what process you follow, inept coders and managers will never be agile.
But they can do Agile.
I suppose the rationale is that the group eventually acknowledges that it is not being productive. Perhaps it has gone through some dead sea effect for some time, and there is increasing frustration with delays, shipping defects and surprising side-effects discovered late in the cycle.
Given two options: a) we are simply incompetent or b) there’s something wrong with our process. Most teams pick option b).
Agile’s pitch is that bad productivity is simply due to the wrong process. And this is true; for competent teams, the wrong type and amount of bureaucracy slows things down. Limiting needless paperwork speeds things up. But it requires competent and honest people and an appropriate type of project. You don’t find a cure for cancer just by doing a bunch of epics, sprints and retrospectives.
The bad team then picks up Agile, but never bother reading the manifesto, and the concept is applied indiscriminately on all types of projects.
Informal inquiries and communication is shunned and the them instead insist on strict adherence to “process”, because deviation from the process is “what lead to disaster the last time” the argument goes. The obvious contradiction between refusing ad-hoc communication and insistence on “following process” and the stated principles of Agile is often completely lost on bad teams.
The web is overflowing with disaster stories of Agile gone wrong (and now I just added one to the growing pile), just as history books overflow with stories of communism gone wrong. And for every story, there’s one where an Agile proponent explains why they just weren’t doing Agile the right way, or that a different kind of Agile is needed, like in this piece, where a comment then reads:
This insane wishy-washy process-worshipping religion is __BULLSHIT__ of the highest order. What you really need is a competent team that isn’t sabotaged by over-eager, incompetent management and hordes of process-masturbators every step of the way.
The Agile process will not fix problems that are due to incompetence. Competent, jelled teams, are probably already agile. Spend more time identifying what value each member brings to the team. Keep score. Cull the herd.
In programming, the whole idea is to avoid re-inventing the wheel, and re-use as much as possible. Some clever coders discovered that there were some mechanism that were used over and over again. For example, the “producer/consumer” mechanism, whereby one or more threads are “producers” and one or more threads are “consumers”. Instead of coders figuring out how to do this properly over and over again, a group of people decided to write a book that described how to solve some of these problems. “Design Patterns: Elements of Reusable Object-Oriented Software” they called it. In the business, the authors became known as the “Gang of Four”.
One of the patterns they described is a “Singleton“: A singleton is essentially a global object, that is instantiated when needed. The idea being that the user doesn’t need to know when, or how, the underlying object is created/destroyed, they can just use it, and all parts of the code then shares the same object. Isn’t that cool. It’s like global variables were suddenly being endorsed in a book, and by some clever people too!!
There are cases (rare, constrained) where a global variable makes sense; it makes sense when the physical properties that the software is trying to model, matches with a single object. E.g. a singular file on a disk or a specific camera in a network. It’s perfectly appropriate to model these objects as global, because there truly is only one of them.
Let’s consider a log mechanism. There may be several things that are logging data, but if all that data goes into just one file, then it’s OK to use a singleton for the file, but certainly not for the log abstractions. If there are three or four different modules that are all logging to the same file, then those modules must have their own logger instance, and the various instances that are made, can then write to the same file using the singleton.
A primitive class diagram could look like this:
Module A -> Log A Parent -> -> Singleton File Module B -> Log B
When you are acutely aware of this composition, you should eventually realize that each logger instance must add some identifier when it writes to the disk. Otherwise you get a log file that looks like this
File Open File Open File Write Failed File Write Succeeded File Close File Close
What you want, in the file, is this
Module A: File Open Module B: File Open Module B: File Write Failed Module A: File Write Succeeded Module B: File Close Module A: File Close
This appears to solve the problem; except there’s a caveat. Say someone writes an app that creates two instances of the parent module. Since the log file is a singleton, all log data is written to the same file. This, in turn, means that two instances of the parent will also write to the same file.
Consider this diagram
Module A -> Log A Parent -> Module B -> Log B Aggregator -> -> Singleton File Module A -> Log A Parent -> Module B -> Log B
We are now in hell.
Module A: File Open Module B: File Open Module B: File Write Failed Module A: File Open Module B: File Write Failed Module A: File Write Succeeded Module B: File Close Module A: File Write Succeeded Module A: File Close
This issue is relatively easy to fix, and it’s still valid to have a requirement that there is just one log file (might be better to create one per parent, but that’s a matter of taste).
But what about issues where things like username, password, preferences etc. are stored in a singleton that contains “user info”. In that case, when the aggregator sets the username, the username change applies to ALL modules, regardless of where they reside in the aggregator tree. It’s therefore impossible for the aggregator to set a different username for Parent 1 and Parent 2. The aggregator, therefore, breaks.
Essentially, the coder might as well have said “let’s make the username a global variable”. 99% of all coders will object when they hear that (or “goto”). But 50% of all coders remain silent when the same pattern is described using the “singleton” moniker.
The morale of the story: don’t use singletons. Not even if you think you know what you are doing. Because if you think you know what you are doing, then you almost certainly do not.
I think so.
The horrible truth is that there are good and bad coders, there are good and bad managers and there are easy and hard projects.
A project, taken on by good coders and good managers can fail simply because the project was too complex and was too intertwined with system that the team had no control over. You could argue that the team never should have taken on the task, but that’s why you warn the customer of the risk of non-completion and bill by the hour.
When doing research on the skills needed to be a good software project manager, there seems to be an implied truth that the coders simply do what they are told, and that coding/design errors are always the managers fault. At the same time, you’ll find that people complain about micromanagement, and not letting the coders find their own solution. I find these two statements at odds with one another.
Coders will sometimes do things that are just wrong, yet it still “works”. How do you handle these situations? Do you, as a manager insists that the work is done “correctly”, which the coder may think is just a matter of taste, and not correct vs incorrect? Or do you leave the smelly code in there, and keep the peace?
If you don’t know how to code, and you’re the manager, you won’t even notice that the code is bad. You’ll be happy that it “works”. Over time, though, the cost of bad code will weigh down on productivity, the errors start piling up, good coders leave as there is no reward for good quality and they’re fed up with refactoring shitty code. If you have great coders, you might not run into that situation, but how do you know if you have great coders if you can’t code?
Maybe you’re the best coder in the world, and you’re in a managerial position facing some smelly code, you might consider two approaches: scold the coder(s), and demand that they do it the “correct” way (which is then interpreted as micromanagement), or alternatively, if you’re exhausted from the discussions, you just do a refactor yourself on a Sunday, while the kids are in the park?
In the real world, though, the best solution is for the manager to have decent coding skills, and posses that rare ability to argue convincingly. The latter is very hard to do if you do not understand the art of coding. Furthermore I don’t think coders are uniquely handicapped in being persuasive and certainly not when dealing with other coders (n00b managers wearing a tie are universally despised in the coding world).
Every coder is different, and act differently depending on the time of day, week or year. Some coders have not fully matured, some are a little too ripe, and some just like to do things the way they always did (or “at my old job we…”), different approaches are needed to persuade different people.
I must confess that this is what I have observed, the few times I have been wearing anything with any resemblance to a managerial hat, I have walked away being universally despised and feared as some sort of “Eye of Sauron” who picks up on the smallest error with no mercy when dishing out insults, but in theory at least, I think I know how thing ought to be.
So,if you are managing software projects and interacting with coders, you need to know how to code.
Here’s a few simple(?) steps to stream pre-recorded video into your VMS.
Then get FFMpeg (windows users can get it here).
Find or create the canned video that you want to use, and store it somewhere accessible.
In this example, I have used a file called R1.mp4 and my RTMP server (Evostream) is located at 192.168.0.109. The command used is this:
ffmpeg -re -stream_loop -1 -i e:\downloads\r1.mp4 -c copy -fflags +genpts -f flv rtmp://192.168.0.109/live/r1
Once this is streaming (and you can verify using VLC and opening the RTMP url you provided), you can go to your VMS and add a generic RTSP camera.
For Evostream, the RTSP output is on a different port, and has a slightly different format, so in the recorder I add:
Other RTMP servers may have a slightly different transform of the URL, so check the manual.
I now have a video looping into the VMS and I can run tests and benchmarks on the exact same feed w/o needing an IP camera.
Level1Techs explains a few things about storage. Worth a look.
Nintendo was the first one among the gaming console companies to enforce strict quality and content controls on games for their platform. Perhaps they saw what happened to other manufacturers that had a more promiscuous approach. When 9 out of 10 games are terrible, people start thinking that there’s something wrong with the platform.
Apple took the same approach with the iPhone. Initially banning 3rd party apps completely, and suggesting that 3rd parties create specially crafted HTML pages just for iPhone. It did not take long before this rule was relaxed, but at least Apple kept some control of their platform by having all apps go through a (shallow) vetting procedure, and ultimately having the ability to pull the app entirely.
In the IP video industry, the VMS companies used to demand that people selling the software were certified. The two primary reasons were that a) it produced a decent revenue, and b) idiots selling your software may tarnish your reputation through no fault of the manufacturer.
Prior to IP video cameras, most installations were pretty straightforward. The challenges were in getting the right coverage, pulling the cables neatly and mounting the cameras properly. Any old electrician understood that when you connected the coax camera to “input 1”, the video from that camera would emerge on the corresponding spot on the monitor. If something happened, you’d eject the tapes, push in some new ones, and that was it.
Getting an IP video infrastructure set up properly is an entirely different ballgame. You still have to pull cables, and mount cameras, but on top of that, you have to deal with a whole host of new problems. You have to keep the OS up-to-date, you have to keep the camera firmware up-to-date, you have to verify that security protocols are adhered to (no “123456” passwords), and if something happens, you have to navigate an often confusing and complex UI that offers 3 different ways to get your footage out of the system. Most of these tasks are trivial to maintain for people who are used to the quirks and understand the meaning of every term, but the majority do not.
If you’re dealing with larger installations, you’re often trying to integrate the VMS with existing equipment, and sometimes you’re asked to make it fit within existing IT policies, which makes things an order of magnitude more interesting. You’re also dealing with people in a position of authority, that arbitrarily demand various things (some possible, some not, some that make sense, some that do not).
As a consultant, I advise people against things I think are counter-productive, unfeasible or impossible. If they still insist on going down some rabbit hole, I will happily go there, knowing that they are paying by the hour. But not everyone is fortunate enough to make that trade.
You could say that I am a kind of prostitute; Naturally, I want repeat clients, so unless the services requested are too crazy, I’ll oblige. I am not offended by any suggestion, but I reserve the right to just say no.
In many cases, though, it’s more like a marriage. And just like in a marriage,. the vendor and the partner must establish and maintain trust between one-another. Without trust, the marriage will not last long, or it will be a long nightmare for both parties. Trust is not limited to “not, technically, lying” (as opposed to straight up lying), it’s also about sharing expectations, plans, ideas, and being honest about what can’t and what won’t happen.
Good marriages also seem to include some sort of equal give and take between the partners; you do the dishes, I’ll do the laundry.
And this is where marriages get tricky. If I mess up the laundry every single time, break the dishes when I try to fill the washing machine, cause water damage to the floors when I mop, then we need to divide the tasks so that I take on tasks that I am qualified to take on. But what if I am not really good at any task? Or at least, not good at any relevant task? Or, perhaps I am confident that I am cooking a mean mac and cheese, but the reality is that it is bland and mushy and gives people constipation.
In a relationship that is too lopsided, one partner will eventually get fed up and leave. And it’s hard for me, then, to gauge whether the mac and cheese is truly terrible, or if it was just something mean and offensive the ex-wife threw in my face. I may, tragically, not learn a single thing from this endeavor.
And so you may encounter people who disables the storage drive through the windows disk manager, and then complain about poor performance. They may not understand how networks work, and demand changes that are time-consuming but will never improve the performance. Naturally, they will complain when they realize this to be true. They may consistently provide false, misleading information regarding behavior and version numbers, and fail (intentionally?) to provide the diagnostic logs to support their claims, and so on. They’re breaking the dishes, shrinking your favorite shirt, and causing water damage.
In those situations, there’s nothing wrong with sitting down, looking each other deep in the eyes, and agree to part ways. Rather than staying in an abusive relationship where backstabbing and offensive slurs are the order of the day.
Nintendo and Apple carefully vetted who they married; setting up strict requirements for those who were allowed into the walled garden. You had to prove that you were a good match, and that you wouldn’t tarnish the reputation of either of them. If you can’t find a good match, then give up, it’s always better to abstain than to settle.
Today, it is not in vogue to be such a snob. Promiscuity is all the rage. Have thousands of connections with semi-random people on social media is the norm. Getting into bed with every conceivable partner is a virtue.
And perhaps that’s why there’s so much shit out there today.