What’s the time for you IT department to get from great idea to a resulting application? This is a very good piece from CIO magazinethat finds many IT departments are seen as too slow. However there are a number of companies that are trying to innovate and find ways to increase the speed at which IT departments can deploy an application and respond to a business need.
One great quote in there is “velocity is more important than perfection”, which is a tenet that I have found to be very true over the years. It’s not that you throw junk out that isn’t well built or tested, but that you don’t try to meet every possible requirement or handle every little issue. The system has to be secure, handle errors, and meet the basic requirements, but it’s more important to get something done and in production than to have it perform and scale perfectly.
Is that heresy to the developers and DBAs out there? Perhaps, but I think this methodology has to go hand in hand with another mantra I heard fromJason Fried: do more of what works and less of what doesn’t. In this case if a system shows promise and starts to get heavy use, it receives more resources and perhaps gets refactoring in real time, even as it gets enhanced with new ideas.
“You want IT to be in constant test-and-learn mode”, another quote showing that IT needs to be working closely with the business to try ideas, learn from them, and move forward. The Agile style of development applies, and in some sense I think this is the future for the strategic IT department of the future.
For the data professional this means that you must learn to model quickly, and with an eye towards a flexible design that might need to change regularly. We need to understand the businesses we work in better so that we can anticipate how requirements might change.
Management has to buy into the idea that applications will not be perfect, they won’t be polished, and most importantly, they are essentially prototypes that either need to have addition resources spent on enhancements or they should be abandoned quickly. However I think this is a great way to develop internal applications that can provide a nice ROI, and be a more enjoyable way for developers to work.
Steve Jones
The Voice of the DBA Podcasts
- Windows Media Podcast – 25.2MB WMV

- iPod Video Podcast – 17.8MB MP4

- MP3 Audio Podcast – 4.1MB MP3




I think you hit the nail on the head. There are great examples of companies out there that are willing to innovate and launch, knowing that they will need to refine while they get feedback from users. Using an agile development methodology with frequent sprints makes this work out very well. You get a product out there, you get real user feedback, and you involve the community in making your product better.
I truly believe this is what makes Google work (as a large scale company) and so many entrepreneurial startups work as well. It’s all about distribution. Even if what you are distributing isn’t necessarily perfect.
I also think that large firms don’t necessarily have to completely abandon their product development rigor; instead, set up a separate innovation team that has the right to take risks. Let them experiment; test the market; screw up. And then when something becomes a real product, you can always transition it over to the “normal guys”.
LikeLike