Dean Roddey
Senior Member
Any interface should be a purely 'on the wire' protocol. The vendor can always provide platform specific helper wrapper libraries around that protocol if they want and support both schemes.
What is wrong with ELK Products inc.?
- Thread starter wojeda
- Start date
tmbrown97
Senior Member
I haven't tested it, but Elk did claim that this could be installed on/run from a portable installation like a USB stick. In that sense, if could be used on public computers if you really wanted (assuming traditional firewalls don't get in the way, which I'd imagine they would).
I'm sure they would too. An option would be to run SSH in portable mode as well and tunnel all traffic over port 443 since that won't be blocked.
wuench
Senior Member
The problems plaguing Elk don't really require developing on other platforms, they just require testing on them. Load VMWare, buy a few licenses and make sure you test. You guys are engineers in the security industry, it is clear you have an understanding of how to properly test, you just need to apply that discipline to your software engineering as well. Test all possible cases, versions, OS's, browsers, etc. If you want to continue to run .Net apps, then make sure they run under Mono at the very least. Better if you convert to something cross platform like Java or HTML5/Jscript.
Many people, including installers, are wanting to carry tablets these days and not rely on lugging laptops around. And it is only going to get worse, in the future, you're going to have to find a way to support those platforms and you can't assume they are going to run Win8.
IMHO...
Many people, including installers, are wanting to carry tablets these days and not rely on lugging laptops around. And it is only going to get worse, in the future, you're going to have to find a way to support those platforms and you can't assume they are going to run Win8.
IMHO...
No offense Wuench but people know what they know and often do what they know. It seems their current developers know how to develop apps on the platform(s) they've been developing them on. While what you explain may not be difficult, it does require someone to make a decision to expend a certain amount of resources (time and money) for the initial learning, development, and testing. The decision makers at Elk may not have an accurate understanding of how much time and effort is involved to include this level of flexibility. But even if they understand the cost and it isn’t large, maybe it is on their list but at a lower priority, so while they’d like to do it, it may not have made the cut yet. Or maybe they're working on it now.
I sense some frustration in this thread on what Elk could and potentially should do. This tells me there is passion, an understanding that Elk has good products available now, and that there is a hope, maybe even an expectation, that they grow to be even better. I sincerely hope Elk is reading this thread and listening to their passionate customers.
David
I sense some frustration in this thread on what Elk could and potentially should do. This tells me there is passion, an understanding that Elk has good products available now, and that there is a hope, maybe even an expectation, that they grow to be even better. I sincerely hope Elk is reading this thread and listening to their passionate customers.
David
wuench
Senior Member
Sure, no offense taken and no offense meant. You're right it is a very difficult and expensive proposition to learn or convert to a new platform and it's a global issue right now, not just Elk's. Elk has an awesome product line and they have always been responsive to the DIY community. I hope they continue to grow and innovate into the future.
We can certainly agree there! J
I'm just starting to get back into home automation (X10 from over a decade ago) and new to the home security realm. I have been waiting for home automation to blow up for some time but it just hasn't yet. I was hoping the Google Automation initiative would go somewhere but it hasn't gone anywhere since they announced a few years ago. However, with the upcoming WIFI standards focused on home automation (or similar devices), I can really see the HA market taking off.
All that to say that I agree with you that companies will need to be competitive as it is a global marketplace and the HA market will be growing and changing. I sure hope Elk is able to make some moves and continue to innovate as you also suggested. If they don’t, others will definitely take up the baton and make it happen. Frankly, I am excited to see what the purchase of HAI by Leviton will mean. The future is always so bright and interesting. J
David
I'm just starting to get back into home automation (X10 from over a decade ago) and new to the home security realm. I have been waiting for home automation to blow up for some time but it just hasn't yet. I was hoping the Google Automation initiative would go somewhere but it hasn't gone anywhere since they announced a few years ago. However, with the upcoming WIFI standards focused on home automation (or similar devices), I can really see the HA market taking off.
All that to say that I agree with you that companies will need to be competitive as it is a global marketplace and the HA market will be growing and changing. I sure hope Elk is able to make some moves and continue to innovate as you also suggested. If they don’t, others will definitely take up the baton and make it happen. Frankly, I am excited to see what the purchase of HAI by Leviton will mean. The future is always so bright and interesting. J
David
Dean Roddey
Senior Member
An important point to remember is that supporting multiple platforms isn't just a one time cost, it's an ongoing cost and the increase in ongoing development cost isn't linear to the number of platforms supported, it's closer to multiplicative. Your development and testing gets far more complex. Unless you are willing to completely separate out a lot of the code into platform specific chunks, then you end up with orders of magnitude more ifs, ands and buts in the code, and developers who can only be sure they aren't breaking anything on their own platform that they understand. You have to now deal with multi-version quirks and limitations across multiple hardware platforms, OS versions, compiler versions, etc..., not just one. You have to have testers and docs people who understand both platforms, not just one. Your testing lab has to become X times larger and more complicated hardware wise, and you need people who can keep it stable and controlled so that your testing is meaningful. You probably now need version control that is cross platform, not something that's tightly and conveniently integrated into your development tools, and all the complexities that setting up and maintaing that requires. Even if you hire people who know the new platforms, you can't just let them run rough shod, you still have to set policies about development, on a platform they understand better than you.
And of course it means that development of new stuff inevitably slows down, possibly quite a lot. You go from a fairly small, tight group working in a single, well understand environment, where they can probably do their own testing a lot of the time, and they understand the code intimately, to a much more ponderous ship that gets a lot harder to turn in any given direction.
Add in that some of those new platforms probably now have to get an official release blessing before it can get on the store to be available to download, and it gets a lot worse. The people who decide that's required have good intentions but in the end I think it turns out to just makes things a lot slower and doesn't make the product any less bug free, because the people who bless the product for release don't know it from a hole in the ground, whereas the people who do can't get to it until it's blessed. And changes made on other platforms can't just stop while the blessing process is going on. So, if it doesn't get blessed, you have to either fork the code to fix whatever is ailing that platform, or go back and deal with changes that might be disruptive. Both of which will further slow down progress and increase the odds of bugs.
And on and on. The complexities are legion and well known by folks who have worked in cross platform development before. If it's a trivial app it's not that bad, but if it's non-trivial, and most useful software is, the complexity scales up very non-linearly to support multiple platforms, unless perhaps you are willing to use some very compromised cross platform scheme that pretty much guarantees it won't feel like a native app on any platform. And even that will get harder now with the gross differences between how desktop and tablet apps fit into the platform.
The C++ XML parser I wrote for the Apache project is probably running on 20 platforms now, from IBM mainframes to embedded systems. But, it's just a sub-system. So no GUI, no requirement for fine grained access to system services or system specific services, no need to support a fancy installer/uninstaller, etc... Once you get beyond that sort of (usually back end) helper subsystem type thing and need to do full applications with GUIs, it just gets vastly more complicated. Once you get into GUI stuff, it can get stupidly complicated because the differences in platforms begin to diverge rapidly.
And of course it means that development of new stuff inevitably slows down, possibly quite a lot. You go from a fairly small, tight group working in a single, well understand environment, where they can probably do their own testing a lot of the time, and they understand the code intimately, to a much more ponderous ship that gets a lot harder to turn in any given direction.
Add in that some of those new platforms probably now have to get an official release blessing before it can get on the store to be available to download, and it gets a lot worse. The people who decide that's required have good intentions but in the end I think it turns out to just makes things a lot slower and doesn't make the product any less bug free, because the people who bless the product for release don't know it from a hole in the ground, whereas the people who do can't get to it until it's blessed. And changes made on other platforms can't just stop while the blessing process is going on. So, if it doesn't get blessed, you have to either fork the code to fix whatever is ailing that platform, or go back and deal with changes that might be disruptive. Both of which will further slow down progress and increase the odds of bugs.
And on and on. The complexities are legion and well known by folks who have worked in cross platform development before. If it's a trivial app it's not that bad, but if it's non-trivial, and most useful software is, the complexity scales up very non-linearly to support multiple platforms, unless perhaps you are willing to use some very compromised cross platform scheme that pretty much guarantees it won't feel like a native app on any platform. And even that will get harder now with the gross differences between how desktop and tablet apps fit into the platform.
The C++ XML parser I wrote for the Apache project is probably running on 20 platforms now, from IBM mainframes to embedded systems. But, it's just a sub-system. So no GUI, no requirement for fine grained access to system services or system specific services, no need to support a fancy installer/uninstaller, etc... Once you get beyond that sort of (usually back end) helper subsystem type thing and need to do full applications with GUIs, it just gets vastly more complicated. Once you get into GUI stuff, it can get stupidly complicated because the differences in platforms begin to diverge rapidly.
If you don't like Elk not supporting Apple, don't buy an Elk system, but... How many security installers don't have a Windows laptop laying around to use ElkRP in the first place?
You really can't expect a company to support installer software for a very small number of people (maybe 10 or so?) who don't have an old windows laptop laying around. Why would any manufacturer lose money to please a few picky people like yourself anyways? Good luck finding a manufacturer in the security industry that does have installer software that runs on an ipad or macbook. Sure, you'll find end user apps, but not installer based programs.
If you're complaining about an ipad app: the Elk M1G protocol is very open. If there's no app you can make one pretty easily and sell it. My personal experience with Elk is they are very nice and actually respond to emails (even though I'm a DIY'er). I had a question about how to handle their new keyfobs using their ascii protocol and they responded very promptly!
You really can't expect a company to support installer software for a very small number of people (maybe 10 or so?) who don't have an old windows laptop laying around. Why would any manufacturer lose money to please a few picky people like yourself anyways? Good luck finding a manufacturer in the security industry that does have installer software that runs on an ipad or macbook. Sure, you'll find end user apps, but not installer based programs.
If you're complaining about an ipad app: the Elk M1G protocol is very open. If there's no app you can make one pretty easily and sell it. My personal experience with Elk is they are very nice and actually respond to emails (even though I'm a DIY'er). I had a question about how to handle their new keyfobs using their ascii protocol and they responded very promptly!
drvnbysound
Senior Member
:hesaid: I was thinking along these lines when I read wuench's post (#50) yesterday... but would have never said it so well.
tmbrown97
Senior Member
You can tell you hit a sore spot with Dean ^_^ I don't mean that in a bad way either. Software Development is a tricky thing to manage; most of the developers in the business are self-taught and honestly a bit inexperienced in business (no schooling; no barriers to entry in the field). There are so many different "right" ways depending on goals...
I watched a single product go from 1.5 developers to 7 developers, a project manager, and a team manager only to get so much less responsive and able to produce - because the new people in charge thought like programmers and not like business people and had different motivators for their actions.
If Elk decides to change this, it's perfectly doable - but takes extremely experienced management to keep it on track so it doesn't go out of control.
I watched a single product go from 1.5 developers to 7 developers, a project manager, and a team manager only to get so much less responsive and able to produce - because the new people in charge thought like programmers and not like business people and had different motivators for their actions.
If Elk decides to change this, it's perfectly doable - but takes extremely experienced management to keep it on track so it doesn't go out of control.
Dean Roddey
Senior Member
One issue in the automation software market (and I'm sure in some others) is that often the people who do it are driven to do it by being into automation itself. They aren't necessarily top notch software engineers or business people, or often neither. If neither, that can be a little bit worst case, because they will both have all of the issues of learning to do business on the fly, and they may have strong ideas about how the product should be, rather than just doing what customers want, and insufficient software skills to build a solid foundation for the future.
It may be an advantage of course, due to knowledge of the subject, but I'd argue that that's not really necessary. Your customers know what they want. The important thing, from a technical point of view, is to just make the product do what the customers need, and do so in a way that keeps it robust and maintainable over time. That takes serious software skills. You may still make all the business errors of course if you don't have the hard business skills, but it's going to be rare to find someone who is heavily endowed in both areas.
I will admit to our being in the latter category. We aren't automation experts, we are software experts. But it's not much of a limitation because our customers (and potential future customers) make it clear what they need. It's our job to make it so. Yes it would be nice to be better on the business side, but there's only so much time in a human life. Still, you learn as you go, and there are LOTS of medium to large companies today who started off exactly the same way and made the same mistakes.
That's why would very much like to hook up with a large company who could leverage our product, provide the business processes and the extra resources that would let us take the product up a number of notches. And, importantly in this business if you are going to do more than DIY sales, it provides the gravitas to convince people to bet on the product (aka company.) The Achilles Heel of small (product based) businesses is always the same. You can't easily get customers until you have customers (or convince people you do have them or will inevitably get them.)
That's at the base of so many of the lies that permeate business, because if you don't convince people you are crushing it (even when you aren't) you may never actually end up crushing it. A lot of people would probably argue that you almost certainly never will. A good business man probably has no problem doing that sort of thing. A technical person, whose personality is grounded in in a rationalist view of the universe, will likely have a lot more problems with that, and will therefore be too honest about the state of the state, and that will mean that that the state of the state will never be as good as it should/could be.
It's one of those great ironies of human nature that, in order to fulfill the requrement of customers for long term viability of the product, you have to lie to the customer about the fact that you have already fulfilled that goal. They force you to lie to them basically, else the product they would like to have may never gain the traction required to remain vaiable long term, which is the thing that prevents them from wanting to commit to it.
And that's also nothing specific to this automation market. It drives the overall economy of the world pretty much. If people think things are going to get better, they will do those things that will make it get better. If they are convinced it's going to get bad, they will do those things that will make it bad. If they believe that your company/products is the new deal with a glorious future, they'll be happy to jump on board and insure that you do have that glorious future. If they think you are doomed, they'll bail out (or not commit) and insure that you are doomed.
That's why getting venture capital, despite the fact that you will almost certainly end up wishing you used more lube, is a much more likely path to success. It allows you to convince people that you are on a solid foundation and going places. So they are more likely to buy your product and make that true. Of course, if you don't make it, then the crash is a lot more spectacular because a much bigger ship hits the ground at high speed. But you probably have a much better chance (in a product based company) of making it.
Anyway, I'm rambling way off topic here. But it's something I think/worry about a lot.
It may be an advantage of course, due to knowledge of the subject, but I'd argue that that's not really necessary. Your customers know what they want. The important thing, from a technical point of view, is to just make the product do what the customers need, and do so in a way that keeps it robust and maintainable over time. That takes serious software skills. You may still make all the business errors of course if you don't have the hard business skills, but it's going to be rare to find someone who is heavily endowed in both areas.
I will admit to our being in the latter category. We aren't automation experts, we are software experts. But it's not much of a limitation because our customers (and potential future customers) make it clear what they need. It's our job to make it so. Yes it would be nice to be better on the business side, but there's only so much time in a human life. Still, you learn as you go, and there are LOTS of medium to large companies today who started off exactly the same way and made the same mistakes.
That's why would very much like to hook up with a large company who could leverage our product, provide the business processes and the extra resources that would let us take the product up a number of notches. And, importantly in this business if you are going to do more than DIY sales, it provides the gravitas to convince people to bet on the product (aka company.) The Achilles Heel of small (product based) businesses is always the same. You can't easily get customers until you have customers (or convince people you do have them or will inevitably get them.)
That's at the base of so many of the lies that permeate business, because if you don't convince people you are crushing it (even when you aren't) you may never actually end up crushing it. A lot of people would probably argue that you almost certainly never will. A good business man probably has no problem doing that sort of thing. A technical person, whose personality is grounded in in a rationalist view of the universe, will likely have a lot more problems with that, and will therefore be too honest about the state of the state, and that will mean that that the state of the state will never be as good as it should/could be.
It's one of those great ironies of human nature that, in order to fulfill the requrement of customers for long term viability of the product, you have to lie to the customer about the fact that you have already fulfilled that goal. They force you to lie to them basically, else the product they would like to have may never gain the traction required to remain vaiable long term, which is the thing that prevents them from wanting to commit to it.
And that's also nothing specific to this automation market. It drives the overall economy of the world pretty much. If people think things are going to get better, they will do those things that will make it get better. If they are convinced it's going to get bad, they will do those things that will make it bad. If they believe that your company/products is the new deal with a glorious future, they'll be happy to jump on board and insure that you do have that glorious future. If they think you are doomed, they'll bail out (or not commit) and insure that you are doomed.
That's why getting venture capital, despite the fact that you will almost certainly end up wishing you used more lube, is a much more likely path to success. It allows you to convince people that you are on a solid foundation and going places. So they are more likely to buy your product and make that true. Of course, if you don't make it, then the crash is a lot more spectacular because a much bigger ship hits the ground at high speed. But you probably have a much better chance (in a product based company) of making it.
Anyway, I'm rambling way off topic here. But it's something I think/worry about a lot.
