Yesterday I had the honor of watching an internal presentation and discussion from the Author of “Lean Startup”, Eric Ries. Mr. Ries is a very well spoken man, who’s clear 
passion and conviction towards the methods of software development for startup companies is readily apparent. The session was thought-provoking, engaging, and truly different. In short, I enjoyed it.
The focus of the discussion was around how to determine if you should spend time coding a feature in your product. As many new startup companies know, it’s not easy to get funding to simply do market research, and the methods in the discussion were as simple as the following: Put up a button that says “Click here for our great new feature“, and simply count how many customers actually click on it. Don’t provide the feature, just pretend.
For a company in startup mode, where they have VC funding, and have to get results immediately, I would agree, that is a GREAT tactic to determine if people are interested. However, the majority of the audience will NOT be working on VC funded startup projects, but will be coding on existing products with a significant base of loyal users. I’m a bit frightened that this method would resonate within the organization. Hopefully, cooler heads will prevail, and we will not adversely impact our customers by deceiving them with promises of features, functions, and capabilities that may never come to pass.
Lastly, the most important, and why I posted it here to effing network, is that in order for all of the fast paced, dynamic changes that were discussed to take place, the key discussion topic that WASN’T mentioned, was the infrastructure to ENABLE all of this dynamic change. The Network.
Think of the network as your highway. Many developers feel that the network should bend, change, and flex like their application designs do. If this were a capability that even should exist, it would be like saying that the current Highway should bend, change and flex when you wanted a new exit to appear to save you time on your commute. If you were in a tiny island country, where you didn’t have highways, only dirt roads, and a vehicle that could cross all terrain, then your agility and abilities would be greatly enhanced. However, if you are going to USE the highways, you have to understand the constraints of the existing roads, and take that into account. No matter how many times you ask the DOT, they’re not going to follow you around to make new On and Off ramps to appease you. 
The same is true of the network, specifically where there are existing applications that are the foundational “bread-and-butter” for an organization. Networks can be designed to be infinitely flexible, however, they aren’t best practice to deploy for “mature” applications with large quantities of loyal customers.
If the network is not designed to provide platforms that can be dynamically modified and manipulated, you’ve now put constraints on the ability of the application to be successful. That is NOT to say that you must have a “fluid” network environment. It means, that in Application Development, there needs to be a clear and solid understanding of the capabilities and limitations of the infrastructure, knowledge of the network, system, and service dependencies, and that everyone has to AGREE as to what is most important. Lastly, if the network infrastructure, system infrastructure, and service infrastructure is supporting what I’ll call “Main stream” applications that are currently running and making profit, that the DEVELOPMENT environment NOT SHARE THAT INFRASTRUCTURE.
When a new “startup” application/service begins to impact core services for all other successful applications/services, you don’t just effect YOUR customers and services, you impact ALL OF THEM. So please, ensure that you develop this startup method in a separate (NOT SHARED) infrastructure sandbox. That way, you can have all of the changes you want, and not impact any stable platforms that your organizations are selling/servicing.
