This sounds like the most desirable feature for any software product. But this can be questioned. Recently it seems every software projects aims for this goal. The problem is that "It Just Works" is not easy to target and so to accomplish. When does a software just work? You will only see this if it does not have any bugs and also if it is highly usable. But then again related to what user expectations? Isn't GoodEnough
- It may be the most desirable feature to yourself, but it isn't to the company. ItJustSells? is the most desirable. Bugs can be extremely profitable, forcing clients to lock into a support contract and keep dangling carrots in front of them to extract more money year after year.
Complete implementation of this feature involves the following aspects:
- After following a standard, minimal-hassle installation procedure, it works with minimal additional configuration required.
- Users and developers do not have to study all the minutiae of the documentation to figure out how to use it. Its externally observable behavior makes sense, and it is obvious how to use it.
- Minimal maintenance is required.
- Version upgrades are smooth.
Even better would be to have that:
- There is no installation process, it just works.
- It requires no active maintenance (maintenance is automatic and quiet).
Some reasons that so many software products don't have this feature:
- Development of the necessary automated installer is expensive. It is cheaper for the vendor to make the buyer do all the work.
- A generic configuration may not perform as well as a configuration tuned for a specific environment.
- A product that can perform in any possible environment often has to be more bloated than one designed to be specifically configured for a particular environment.
- Security concerns may indicate the need for the product's features to be "turned off" by default, and explicitly "turned on" by an administrator.
- Developers may believe that all users have (or should have) all the necessary knowledge and available time to figure out how to make it work, so there is no need to make it easy.
- Developers do not know what the user wants so they make everything configurable and don't provide reasonable defaults.
- Management will not authorize improvements if a capability works but the users find it difficult to use. Too much reliance on the "If it ain't broke, don't fix it" principle.
- Requirements for forward or backward compatibility prevent changing default behaviors that are obviously wrong.
is a fairly good example of this. Knoppix is a variant of Debian, a Linux distribution, that comes on a single CD. To use it, you put the CD into the CDROM drive and turn on the computer. It doesn't install to the hard disk but instead runs straight off the CD. As it starts up, and with no prompting, it detects all of the computer's hardware, connects to the network if possible, then starts up KDE.
This is one of the main driving forces behind NFC on a 2013 SmartPhone
-- the ability to quickly send a file without having to fiddle with Bluetooth pairing, connection and all that stuff. If you have two phones that support Android Beam
, you just open the app with whatever you want to share, touch phones, tap "Send", and the phones will automatically negotiate a Bluetooth connection over NFC. To the user, ItJustWorks
. (Samsung took this one step further with its mod S Beam
, which uses wifi on ad hoc mode, thus achieving much faster transfer rates than Bluetooth -- though this only works if both phones are Samsung Galaxy S3, S4 or Note IIs).
IJW is also the name of a New Zealand-based software business, which specializes in .NET solutions (http://www.ijw.co.nz
). The connection with Microsoft's IJW technology is purely coincidence, however.
(IJW) is also the name given to the MicrosoftDotNet
functionality in Managed Extensions for C++, in which DotNet MicrosoftManagedCode
can "tunnel" into the world of DistributedInternetArchitecture
. See article at
Anyone who have found a need to use this in a Business Application please share your experience here. I am curious as to what situations may benefit from this, and what limitations of use exists
It wins big when you're not doing green-field development and you need to bring existing code into the New! Shiny! managed world, or when you need to consume vendors' libraries with C-based APIs. Sure, you can
do this with p/invoke in any of the other .NET languages (see http://www.pinvoke.net
for an attempt to start producing signatures for the entire Win32 API) but IJW has two advantages:
- Just consuming the headers is a lot simpler than trying to craft up function and structure declarations which p/invoke will be happy with
- Even when the entire Win32 API has freely-available p/invokable signatures, third-party libraries will need consuming
The biggest limitation derives implicitly from its biggest win: IJW helps you overcome the ImpedanceMismatch
, but at the cost of a second ImpedanceMismatch
- that between managed, GC'ed references and classic pointers. The C++CLR release of the ManagedCeePlusPlus
language should avoid this problem to an extent by distinguishing syntactically between managed references and unmanaged pointers (the former will use ^, while the latter will stick with *). StanLippman?
has blogged extensively on this - see, for example, http://blogs.msdn.com/slippman/archive/2003/12/02/58439.aspx
So now it will be possible to be a four-carrot programmer? I can't wait!
's IJW mechanism should also lets you link managed extensions code with the odd static library, which makes things ever so little simpler than relinking a 3rd party lib as a DLL, giving you Yet Another File to distribute - you make a managed wrapper around the static lib and have all relevant code neat and tidy in one place.]
functionalities continue in the upcoming WindowsCommunicationFoundation
, but it will be called "called C++ Interop". See more at "Moving to DotNet
..." at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/movNETWFX.asp
See also DoesWhatItSaysOnTheTin