Tag: software development

I think that the lottery mentality that so many executives of companies have these days is bad for business. The idea that someone can be promoted from a director or vice president to CEO and then earn enough money in bonuses, benefits and stock options to retire is silly. People that lead a company should make more, but their jobs should be no more secure than anyone else’s in the company, and they shouldn’t be paid multiples more than their direct reports. If they lose their jobs, they should have to get a new one, just like the rest of us.

Last week LInkedIn had an initial public offering (IPO), which was very successful. The company raised money, which hopefully will help it grow, and many stockholders and investors became rich. That might not be important to data professionals, but the news may have caught the attention of your management, and that could be good for IT.

The CEO of TheLadders.com wrote a blog about the event, and he brought up an interesting point. Executives and management in many companies probably are thinking that social networking, or just online engagement with customers,  has an impact on their business. How do they get better engagement? Better Information Technology.

While I’m not sure this will be pervasive throughout all companies and industries, there will be executives that want to build new systems and move faster. They will want new applications, which means new databases, and for some of us, this will be the chance to get a better job, build a strategic application, or just get a little more budget for our group.

It’s also potentially an opportunity for you to be pro-active. Maybe you can suggest a few new ideas for projects or enhancements that you might want to tackle which would improve customer engagement. Maybe you’ll even get the chance to have some fun at work.

Steve Jones

The Voice of the DBA Podcasts

• Windows Media Podcast – 22.0MB WMV
• iPod Video Podcast – 15.7MB MP4
• MP3 Audio Podcast – 3.6MB MP3

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 was listening to a StackOverflow podcast awhile back and there was a discussion on  programming, debugging, and how software has changed. One of the interesting things was that we have solved many programming issues and are building more complex software, which has resulted in the types of bugs that we often find today are different than the bugs many of us older folks used to deal with in programming.

When I was writing code as a youth, we often had bugs that were process bugs. We were trying to get software to do X, and struggling with actually how to tell the computer that X should occur. I heard a few people on the podcast mention that they typically didn’t have those bugs too often, at least not once the software was at a point where they would release it for general use. Instead they talked about finding bugs that were issues because the flow of the software wasn’t what the user expected. These bugs were problems in terms of actually determining the way the software should function in order for it to be useful for the user.

That’s an interesting idea. As we’ve built more frameworks, abstraction layers, and other tools to help us program, you would expect that many simple bugs, things like issues with memory, buffer overflows, etc. would become less prevalent, and more often we’d have these flow bugs that are based on how the software is used. It’s a topic that begs this question for a Friday poll:

Do you think your code has more bugs because of problems building the algorithm in code, or because of a lack of understanding in how the user will interact with it?

With more “agile style programming”, rapid development and changing of requirements, one would think there are more of the latter bug. However let us know this week what you think. Reflect on the issues that you have had in writing code, reports, user interfaces, even more complex calculations. Are there more problems with actually understanding the design of what you need to build, or the actual implementation once you understand it.

Steve Jones

The Voice of the DBA Podcasts

• Windows Media Podcast – 22.6MB WMV
• iPod Video Podcast – 16.5MB MP4
• MP3 Audio Podcast – 3.7MB MP3