CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Steve Hebert's Development Blog

Steve's Blog - From .Net to dotMath and everything in between.

January 2005 - Posts

  • Moving .Math source

    I'm moving the .Math library from the GotDotNet servers to SourceForge.  The server responsiveness and now repeated errors in getting to the old site has prompted the change. 

    I'm still happy with my decision to host the documentation on my own site and that will remain the same.

  • A very nice write-up on IIS Compression

    I just went digging for IIS compression details and found the following article.  The article makes mention of the Port80 Software Blog... subscribed.

     

  • The Revolt of the Corporate Consumer - now freely available!

    David Bank, the author of “The Revolt of the Corporate Consumer” that I blogged about here, sent me the following URL to his article made freely available by the Wall Street Journal. 

    David took the time to talk to the people controlling the content servers and they responded by making it available to non-subscribers as well.  Thank you to David and my hat goes off to the people at the Wall Street Journal!  Wow!

  • "The Revolt of the Corporate Consumer" article

    (Authors Note:  I'd like to thank David Bank and the people at the Wall Street Journal for sending me the URL to a version of his article that's available to non-WSJ-subscribers. I've modified the link accordingly.)

    “The Revolt of the Corporate Consumer” article by David Bank appears in today’s Wall Street Journal.  Subtitled “How companies are squeezing tech suppliers to get a bigger bang for their software bucks”, the article does a nice job of reviewing the combining factors today that are changing the software market landscape. Mr. Bank hits on a number of factors affecting the software community, but I think it’s interesting to look at these in light of how the development community is responding.

    Demanding Standards

    I thought this entry was interesting in Bank’s article, but he blends this portion of the article with the fact that “customers are using their new clout to force vendors to deliver software that is more secure and reliable.”  In the production scheduling area I’m involved in, we do not see strong push toward using standardized integration, however we are taking a lead role in providing these types of integrations – I believe this is only a matter of time as the market matures.

    I think Bank’s comments on security and reliability really connect with the basic ideas behind recent approaches in the development community.  For example, test-driven development is an approach aimed at providing a more stable and confident release pattern using a repeatable process with a full complement of tools.  While TDD provides a number of other benefits on the development front, when viewed from the customers’ perspective it simply makes good business sense.

    The security front is a different story right now, with this being a hot-topic across the industry.  We are beginning to see security “sniffer” tools being released from companies like Compuware to introduce a regimented approach to the problem.  Security is a different ballgame as developers are constantly playing catch-up to the “black-hat” hacker community.  However the application space faces a slightly different set of intrusion priorities than an OS vendor faces. I think it’ll be interesting to see how tools will adapt to each concern. 

    Cutting Maintenance Costs

    Banks discusses the fact that customers are dissatisfied with both cost and complexity of software.  Both factors impact maintenance costs with annual maintenance contracts typically priced between 15% and 25% of the initial software license and the setup and maintenance burden imposed by installation. Customers are pushing back against large up-front license fees and software companies are developing models where customers pay for what they need. 

     On one front, development approaches such as “service oriented architecture” and standards surrounding XML Web Services are giving solution providers the ability to develop standards based integration and the opportunity to host data storage and configuration offsite even when relatively tight integrations with existing systems are needed. While reducing the clients maintenance burden, this separation also allows for usage monitoring and billing opportunities that are far more difficult in a remote-installed application.The “soa” mantra also forces (when used properly) a simpler integration pattern.  By forcing the application provider to express integration points in terms of simple, knowable and describable transactions happening largely within one call forces development and corresponding documentation to focus on simplicity.  As with any tool, the goal can be missed with a poor implementation, but SOA does not promote (in terms of operation, scalability, bandwidth, etc.) the types of integrations used with in-process/stateful objects typical of earlier systems.

    Sharing the burden

    In this section, Bank discusses the demand for “shared responsibility” that he characterizes for demands that include easier patch management, more secure-code and fewer bugs. While Banks already discussed secure code and fewer bugs, Bank infers the point that customers are demanding a more responsive development environment. I believe the biggest response to this point has been the daily build cycle and a correspondingly active QA process.  Maintaining a constantly released piece of code forces the developers to focus not only on features, but on getting the code installable from day one.  This idea has been around the industry for many years – I was first introduced to the concept in Jim McCarthy’s book nearly 10 years ago, but this approach is getting far more traction today than it has in recent years and build automation tools are making there way into development tool offerings (such as Microsoft Build). 

    Deep Discounts

    Bank discusses the fact that in the Oracle/PeopleSoft battle, court documents revealed that both companies were routinely discounting their software prices 70-90%.  While he discusses the significance of open-source software in this role, I didn't feel that he made a solid case for it as having a casual relationship to the “Deep Discount” issue. I think the more interesting angle is in the ERP market itself – when is someone going to pull a “Microsoft” on this market.  What I mean by this is offer the product at a 10th the listed price and even make the product available to support people in non-operational situations virtually free.  For example, give the IT people who need to tie into the systems access to the software before the purchase and the corresponding tools and you provide another door into companies that sale reps cannot create or reach.  It sends a message to companies that you are confident in your product offering and willing to work hand-in-hand with your staff to be successful. I wonder if Microsoft will see the light, or simply try to play ball with everyone else in the ERP market.

    Demanding Results

    I find this section to be the most compelling and dead-on.  Software companies must focus on getting benefits and results to the customer.  This may go beyond the realm of the software itself and software companies need to realize that the software installation is merely a starting point in proving worth.  To be completely fair, I believe there are many companies purchasing software that cast a weary eye and rightly so.  The “maintenance contract” is usually viewed as something that benefits the vendor instead of the customer.  Battling that perception while providing a hands-on approach to customers is not a simple battle, but one that will be necessary for software vendors to succeed.

    I like Bank’s quote of Mike Lawrie of Siebel Systems who said “It’s not just about making the best software, it’s also about helping companies get to that business outcome and get the value from the investment they’ve made.”

    Summary

    I enjoyed Bank’s article and it’s very worthwhile reading. Living in the software-space it’s unsettling when you look at the number of forces conspiring to take down the software gravy-train that’s been in place for a number of years.  That said, even a fool knows it had to end sometime.  The important thing to remember is that changes and improvements to software methodology need to be viewed with a constant eye toward the customer.  Each developer needs to make their own processes better not only to make the software and it’s corresponding processes better but for the sake of staying in business and growing market share. 

  • friday post: article on the "Commodore 64 Joystick" designer

    I read an interesting article on CNet today about the designer of the Commodore 64 Joystick game sold on QVC - Jeri Ellsworth.  It turns out Jeri started with the Commodore 64 back in the 80s and the story follows how she dropped out of high school and became a self-taught circuit designer.  It's a pretty fascinating story. She's been signed on for a series of projects with the same toymaker that pulled together the C-64 Joystick project - good for her!

  • detecting SQL traces and fun with encryption

    I'm putting together a sql update script execution application and one concern is that someone could grab the script during execution by having a sql trace running.  After checking out the sql server documentation, I came across the following select statement:

    select * from :: fn_trace_getinfo(default)

    If one or more rows are returned, at least one trace is being run on the system.  Cool stuff!

    This has been the one caveat to securing the process.  I'm using the SharpZipLib to compress the script before using TripleDESServiceProvider class to provide encryption.  As a test, I reversed the process to see how much repetition would appear in an uncompressed script.  Here are my numbers:

    Script File Size = 3.9MB
    Encryped File Size = 3.8MB
    Encrypted then Zipped File Size = ~<3.8MB
    Zipped File Size = 370000 bytes
    Zipped then Encrypted File Size = 369000 bytes

    I found it interesting that the encryption creates a random enough pattern to the data that compression doesn't work well.

    I've read that compressing a file before encrypting is supposed to be more secure because it makes cracking the encryption. I imagine this could be true since it introduces another step that must be discovered in the process of hacking the file, however I wonder if it would be easier to hack since you'd know what the zip header has to look like.

More Posts