1st quarter
marketing to engineering: just make the demo work.
engineering: okay.
2nd quarter
sales to engineering: we sold $200K today. But all the features say "not implemented"?
engineering: uh, only the demo works. call us later.
3rd quarter
tech support to engineering: documentation says that we can speak the &#$%^@#$ protocol. Do we have a server that speaks &#$%^@#@?
engineering: never tested that!
Servers and Drivers
The end-to-end network that we know as the Internet is based upon a fundamental set of applications such as Telnet, FTP, Email (SMTP), and of course, the world wide web, carried on HTTP. Pretty much every single one of these core protocols is based upon clients and servers.
Innovation is possible because the set of protocols is not closed - it can always be extended. Additionally, most protocols provide means for extensions.
Many innovators are creating new protocols for devices and systems that they intend to sell. Be it IPv6/WAP/GPRS enabled mobile phones, or network readable water meters.
The device itself is challenging. It may need to deal with lots of random inputs, relaying them across the network. It may need to speak a custom protocol, or an augmented version of a well known protocol.
When it is ready, what will it talk to?
How will the device get tested?
What diagnostic features will you need?
Many a company have hardware and firmware working on time, but nothing to demonstrate against - this is hardly surprising, the team is focused on deliverying the core product.
Let me help you on the rest. I can help you with:
I have extensive experience implementing network protocols - both clients, servers, nodes in peer-to-peer networks, firewall proxies. I am experienced with the advanced event driven programming that is required for dealing with multiple events from the network.
I have spent most of my career doing network and system security - this means that your first release won't make your name infamous due to a security flaw.
I understand how to build an environment where people can work efficiently, and focus on the key objective: on-time, on-budget, finished products.
I have extensive experience with eXtreme
Programming, but work well with any methodology.
Demos
A demonstration system is important. It shows that your team can produce the product you told your investors you could do, and it communicates your core value proposition to potential customers.
But, demos can be hard - they have to actually show something. Blinking lights are important, but a tangible demonstration of why your product should be picked is still key.
I have a unique talent for translating marketing speak into geek speak, and vica-versa. I know how to twiddle-bits, and how to explain the need to do this to non-techies.
System Administration
You throw a party - the first bits move through your prototype, and the demo comes alive. This may sell the product to the CTO. It may not sell it to the IT department - they actually have to install it and make it work. Ultimately, if your product is hard to configure, and hard to manage, the IT people will complain, and your competitors' inferior, but more easily configured product may replace yours.
This is a place where marketing and engineering get into a problem - marketing was happy with the web interface. It should always be that easy. Engineering was happy when the LEDs blinked the right way. Tech/Field support has to deal with the gap in between - how to get useful diagnostics.
Getting a proper management interface is a core part of designing and packaging the product. Sure, you say, but you were talking about network servers over on panel 1! That's because the hard part about building network servers and system device drivers is dealing with the failure cases.
This why I get on-time results while others have overruns. I know that building in diagnostics, debugging and admin interfaces has to occur up-front. These are also the parts that core designers may want to delegate - but they have to be done right.
Consulting Services
Contracting services