Allegient

What does Black Friday shopping have to do with risk management? Sure, both may include being up late at night and rushing from one location or meeting to another. And then there is the pushing and shoving (oh… wait… that one is just for the shopping). But seriously… there is an interesting parallel that I would like to share.

On a trip to scout out some laptops, I encountered a number of people lined up (with tents) outside of a Best Buy store Wednesday evening, waiting for the doors to open sometime Friday morning. There was a television they wanted to purchase (yes, I asked them) at what I would hope was a near give-away price. Obviously, the problem is that the store probably would not have enough of the televisions for everyone who might want one at that price. Put another way, there was a risk that a person wanting to purchase one of those televisions may not be able to do so. The obvious means of mitigating the risk in this scenario is to be among the first people through the door when the store opens. So how does one eliminate almost 100% of the risk? Well, in this case it means missing Thanksgiving dinner with family and spending 36+ hours in very chilly weather. Can you avoid paying such a high price? Sure, you can line up later or arrive after the store opens, but you would also run an increased risk of not reaching your goal – the great deal on the television.

A business needs to make the same trade-offs. I have seen managers who believe that they need to eliminate 100% of a particular risk occurring on a project, or an organization who insists that the system must be available 24/7 with zero down time (no, it wasn’t NASA). While it might be possible to get to 100%, or at least very close, the cost of doing so is usually prohibitive. In fact, careful examination usually reveals such a high degree of system availability may not even be necessary.

On Black Friday, I was not willing to pay much for the deal I sought. It was at least noon when I entered the store Friday after the crowds had faded. There was a very real chance that the product would not be in stock, but I was prepared to live with that, should it happen. In other words, that was an acceptable risk for me. As it turns out, there was product sitting there waiting to be transferred to my shopping cart. That was the case for many other things on the shopping list, as well.

So allow me to summarize what this recent shopping event was a reminder of, and possibly open myself up to criticism for stating the obvious: every person and every client will value things differently, be it keeping a project on schedule, or purchasing a 60-inch HD television. One neither wants to take on too much risk, nor pay too much for avoiding trivial risk. Fortunately, there is an abundance of tools and techniques that a skilled consultant can bring to bear on the issue. An experienced professional can help identify hidden project risks, assess their impacts, and help prioritize them. As for me, I am glad I took the chance on Friday and did not camp out for my shiny new 16GB USB drive. project management, developer, allegient, technology consultants indianapolis

GDG Files Full of Money

After I made a monumental blunder with a GDG [Generation Data Group] file, my manager gave me a monumental project that intended to bridge the gap, dynamically, between "DB1" and "DB2."  I was a brand new programmer--kind of like a brown belt in TaiKwon Do--knowledgeable enough to be dangerous. My manager, Phyllis, who herself had worked her way up from nowhere inside a staid Midwest Insurance Company, gave me the assignment.

There was a single file--called a GDG or Generation Data Group file. The file had the same name, but yesterday's version was called 'TheGDGFilename(-1).' Today's was called 'TheGDGFileName(0)' and tomorrow would be called 'TheGDGFilename(+1).'  It's a convenient way to automatically version files such as the one I had to work on.  In the file, every record represented a draft (check) for thousands of dollars that was going to be sent out to pay a doctor or hospital. My manager Phyllis explained there were some bad records from Pennsylvania that I needed to sort out.  I found there were 7 Pennsylvania records.

I wrote my bubble sort and it worked perfectly. When I was done with the run, I was surprized to see there were still bad records--the same ones I had sorted out. I ran my COBOL program again and again and the Pennsylvania records were still there.  I ran it 7 times.

At about this time, in the basement of the home office, five stories below me in the print room, a color printer went crazy. It started shuttling in the check-blanks paper like lightning. As the flood of draft checks started to pile up and the envelope machine worked to get those checks into envelopes, a wise old pressman--Hans, no doubt with a handlebar moustache--slapped the red button on top of the check-writing machine and got Phyllis on the phone.

When Phyllis got it all sorted out, she realized my mistake. I had not written as I should to the +1 generation but back to the same 0th generation that I had read it from. So, I failed to delete the Pennsylvania records overall and raised the number of rows in the file into the thousands.  Phyllis sent me into a room where a SWAT team had assembled, trying to get rid of the duplicates.  She told me "Don't say a word ... just sit in there and watch all the people cleaning up your mess."                       

                      
IMS Is Running Out of Space: Help, DB2!

A few months later, after the issue with the "drafts" had faded, Phyllis and our team were facing a huge problem: we had one of our systems that was stored on an IMS hierarchical database--a non-relational beast that resembled an Alexander Calder mobile sculpture.

We stored Claims in the IMS database because it was so fast, but we were running out of physically addressable space in IMS. So, we had to purge our data off to a long-term DB2 database and a claims table with 60 million rows. So, because the IMS database was almost out of space, we constantly shuffled slightly old claims--a few weeks--off of the IMS database and on to the DB2 one.  It was a batch job.

If someone called in and asked a Claims Examiner about a claim from last week, it could be found right away. But if that same customer wanted information about a claim from two weeks ago, tough beans: call back tomorrow. And if tomorrow you ask for another old claim, tough beans: call back tomorrow.

We brought in a very smart DBA, and in two hours he described what needed to be done to solve this problem. It took me a year, among other tasks, to complete what that DBA outlined. It involved making a dynamic COBOL module, about the closest you could get to OOP without leaving COBOL behind.

For a few weeks during the Christmas lull, I mapped out the entire old mainframe system.  That effort taught me about the value of mapping systems and made it possible to untangle the spaghetti, make a dynamic COBOL module, and run it in both dynamic and batch modes. It was hugely important to our company, and I didn't mess it up, as Phyllis noted with satisfaction. 

What are the characteristics of software development and integration projects that result in the highest sense of quality, success, and satisfaction? 

The traditional view is that the "deliver on-time and on-budget" mantra typically hailed as the central project metric is the only thing that matters.  However, experience doesn't bear this out.  An on-time, on-budget project that doesn't meet the business need or is unusable by the target audience clearly doesn't deliver success.  Budget and schedule remain important, but a higher value result easily justifies more money and more time.  Likewise none of us would want a project that's delivered under budget and early if it didn't address our real world business need.

The client perspective of the quality of a consulting or project engagement may be quite different than the typical consultant's perspective. The client's perception of quality in both the work product and the engagement itself combines the key elements of satisfaction – value, efficacy, and experience. 

We consistently push the team to look for ways to measure ourselves and deliver on these key elements of client satisfaction in addition to the simplistic measures of cost and schedule.   I believe it’s the ability to maintain this balance of both the client’s satisfaction values and the project timeline/budget metrics that has built our high percentage of returning clients that have come to trust our delivery services since 2001.   Technology Consultants Indianapolis, IT Consulting

The compiler doesn't care if the code is sloppy, just as long as it's right.  That is sadly the attitude of many developers I've worked with over the years. They know the compiler removes all unnecessary spaces, ignores comments and doesn't give a hoot if their code is sloppy, if variables are badly named, or if it's all a huge pile of spaghetti.  But when it's time for modification ... I care.

Compilers don't have to enhance someone else's code, nor do they need to dig through the mess to figure out where the bug is.  Sloppy code is a bug magnet.

It's all about the signal-to-noise ratio. For example: I am a native speaker of English. If someone hands me one hundred sentences in English, it's likely that I will understand all 100 of them. All the information is signal. There is no noise among the 100 sentences. But what if 40 of the sentences were in Mandarin Chinese which I don't even read. Then 60 sentences would be information--and 40 sentences would be noise. From those 40 Chinese sentences, I get no usable signal--it's just noise.

When I see a chunk of code like this--all of the information is embedded tightly with the noise.

• The code is squished together vertically, making it all a dense chunk of type.
• The curly bracket begins--as is Holy Writ among C++ developers and other misguided folks--right after the method name, thereby breaking the obvious symmetry in the placement of the curly brackets.
• The developer has also chosen to use the code style called method-chaining. That style of coding is perfectly legal. It also makes the code unreadable and subject to errors during re-factoring. If the developer wants to debug that section of code, the only convenient way is by giving names to the anonymous objects.
• The same objects need to be created using anonymous objects. There is no advantage to coding with method chaining.
• Method chaining is popular among lazy developers.

The squished code above, SignalIsHiddenAmongTheNoise, makes it hard for me to separate the signal from the noise. I cannot glance at that class and tell what it does, because it is coded in a way that hides the signal in the noise. I can't look at it and tell: I have to pick it apart. The developer is not making it easy to read the code.

• Because the curly brackets are placed symmetrically, it's easier to see where the method scope begins and ends. As we nest code this becomes significant.
• Lots of white space appears and is used to make logical groupings
• Lining up the curly brackets makes the code easier to read.
• It delineates the scope of a patch of code.
• Instead of lazily chaining together the methods, I spend a tiny fraction of memory to make the objects named. There are many benefits to this.
• Immediately, it's much easier to see what the program is doing.
• Instead of piling up a bunch of method calls in a confusing manner that forces me to pick it apart to understand what it does, I can see the code one statement at a time--the way it actually runs.
• I see the types of the objects created.
• If I want to debug what their variables contain with an IDE, it's much easier with named variables.
• If I want to change the the type of a variable used in several places, I won't catch these anonymous uses of the class until run-time, when I get an exception.
• When I line up my variables in a line, it shows clearly they are all in the same scope.
• (And you only should line up variables that do share a scope)
• I can clearly see on which objects the methods are executing because they're lined up in a row.

Position Summary
The Mid to Senior .NET Developer to work in a team to design and implement a new system from the database to the UI.  Must have good to excellent experience with .NET 2.0+, C#, ASP.Net, SQL Server 2005/2008, and experience working at a consulting firm.
 
Responsibilities:
• Experience with developing Microsoft-based server applications, using service oriented approaches and .NET Frameworks for integration with business partners, transaction processing, web-based interactive applications, relational databases and full lifecycle development
• Implement solution architecture by building components and custom designs; prototyping; data migration; maintaining technical integrity and consistency; documenting system
• Ability to participate in a team structure, articulate solution risks and barriers; recommending project approaches; preparing time and cost estimates
• Validate system performance by developing and conducting test scripts; completing bug fixes
• Manage customer relationship by communicating architecture standards and frameworks; answering questions; resolving concerns and issues
• Conduct and participate in peer code reviews
• Conduct and participate in code build and merge processes for system build
• Validate system performance by developing and conducting unit test scripts; completing bug fixes
• Enhance overall team accomplishments and competence by planning delivery of solutions; answer technical and procedural questions for less-experienced team members; teach improved processes
• Improve information usefulness by tracking emerging technologies; evaluating their applicability to business goals and operational requirements
• Increases organization effectiveness by identifying opportunities to leverage solutions to other engagements
 
Requirements:
• 3 years of Information Technology development experience
• Demonstrable understanding of UML and business process modeling
• Familiarity with web based application development and technologies like Microsoft SharePoint, Microsoft Biztalk, J2EE, XML, etc
• Experience with software development lifecycle
• Excellent business function and process analysis and visualization skills
• Very strong written and oral communication skills
• Problem solver with strong analytical skills
• Outstanding interpersonal skills, strong work ethic, self-motivated, and excellent presentation skills
• Self initiated, enthusiastic and driven to succeed
• Ability to work independently, but also successfully work on a team
• Detail oriented and sound independent judgment
• Excellent Desktop Tools Skills, including Office, Visio, MS Project
• BS in Engineering, Computer Science or related field preferred

Please email resumes to jobs@allegient.com

Allegient is a leading provider of business and technology solutions for mid-sized and enterprise organizations, leveraging best practice methodologies and proven technologies to improve business processes, collaboration, customer relationship management, information management and business intelligence. Headquartered in Indianapolis since 2001, Allegient is known for providing consultants hailing from Big 4 and Fortune 500 companies with strong professional and technical skills along with a good project management foundation.  Allegient is ranked the 2nd largest regional web site developer by the Indianapolis Business Journal and is currently the only Microsoft Services Ready Partner for Portals and Collaboration for Indiana and among a select few Microsoft Gold Managed Partners in Indiana.

By the second day my jaw was on my desk. I could not believe that the developers in such a large and prosperous company had written such a hacked-up system.  We developers define "hack" as a style of software development that, while it may get the job done, is substandard.  It represents a "bug magnet" or a style of coding that invites errors.

I had been hired to work as a contractor for a big, famous New York corporation. Their existing stable of Java developers had not updated their skills in about ten years and so I was stunned at what I found.

1. Plain old JSPs with view code and database-access code intermingled in the JSP.
2. Java methods created on the fly in their JSPs.
3. Hard-coded usernames and passwords inside the JSPs.
4. No source control
5. No upper case letters used anywhere except in captions.
6. A JSP-Servlet environment with no servlets.
7. JSP pages wide open to SQL Injection

1. One of the most fundamental ideas of modern software development is the pattern called MVC for Model-View-Controller. The idea is that you don't just do anything anywhere. Instead, you confine any code that deals with the way a page looks in the JSP or the View layer. You confine anything having to do with the data and its access to back-end resources to the model. The Controller controls how requests originating in views find their right model. The benefit of this design means you can modify the view without affecting how the data is accessed. However, in Hackville any change to how the page looked inevitably affected how you accessed the data because the two were co-mingled.
2. Normally, all Java code will be confined to the Servlets or deeper back-end layers. However, the JSP spec does allow a developer to make the damn-fool mistake of creating a new Java method in the JSP. At Hackville, Inc, they were doing that.
3. It seems pretty obvious that hard-coding a database username and password in the JSP is a bad idea. Not that any user on the web-page could see them--they could not--but it just meant, among other design considerations, in the least you would need to change a password in multiple JSPs. Such things as database usernames and passwords should be confined to a property file that is accessed only from a DAO layer far away from the JSPs.
4. No source control meant that the developers at Hackville had no idea what source they were using. Each developer stored the source code for the code they had written in their Unix home directory. Within the first week of my start, they had lost the source code for a departed developer. So, the only way to recover was to decompile the .class files or find any possible source, compile it and see if the resulting class file sizes were the same. In short, a nightmare.
5. One of their major developers apparently didn't feel like using the shift key. So, all of the source code he wrote was strictly lowercase.
6. The presence of all the Java code in the JSPs was given as the reason why no servlets were "necessary."
7. Finally, a practice had been followed of accepting input directly from textbox fields and then using that data to directly build a SQL query that was used in a Statement to access the database. That meant that any clever user could bypass the need for pesky things like a password and inject any arbitrary SQL code directly into the database--no questions asked.

It is fairly common for a business to determine that it needs some type of technology solution. The important question that follows, however, is whether the solution should be built from scratch, or purchased "off the shelf." Here, the right choice can save a company huge sums in both the short and long term, and help avoid an endless morass of run-away work arounds, ill-sought functionality, and critical compatibility issues. That said, some of the factors affecting the choice might even surprise you.

Your Business is Unique

For the most part, no two businesses are exactly the same. It only makes sense, therefore, that a unique business will need a unique solution. There is a serious advantage to having a system that matches your company's needs and processes. Some of the advantages are:

• Less training by the staff because they are using a familiar process
• Screens may be made to match familiar forms, further reducing training and errors
• If the new system has processes that match those that have already passed regulatory muster, certification and approvals will be greatly simplified
• Unique pieces of information normally tracked by the company will not get lost, or have to be managed outside of the system,  because it is not included in a commercial solution
• You can avoid unnecessary steps and constraints that are contained in a generally marketed package

Custom fitting comes at a price

Like having a suit custom made from scratch, a custom-built technology solution is probably going to be more expensive than a solution taken straight off the rack. Unless your organization has a track record of successfully completing this type of work, you definitely want to seek the help of a qualified consultant. It has been my experience that most companies greatly underestimate the immediate cost of developing a system from scratch, and managing it to a successful conclusion. Here are some of the factors to consider when evaluating the build option, and some of the benefits you can expect from your consultant:

• Assessment of the specific needs to be addressed by the new system is critical
• Once scoped, a clear definition of what is to be built will be needed
• As with any major business solutions undertaking, there will need to be a breakdown of the project into manageable tasks
• Estimation of the materials and effort needed to build the system is essential (do not underestimate this effort as it can be a challenge for the most seasoned professional)
• Defining of parameters that will serve to track progress and success
• Identifying the skill sets needed throughout the lifecycle of the project
• Expert project management
• Testing and other quality-related activities

Whether a company goes it alone, or brings in professionals to aid in development, do not underestimate the costs. I've seen many projects halted because of budget overruns that were solely the result of poor initial estimates. This is not to say this approach is to be avoided. It is essential, however, that the return on investment be realistically evaluated.

A Case for COTS

A Commercial Off-The-Self (COTS) package is software and/or hardware that can be purchased and implemented without the need to create the software and build the hardware yourself. Because multiple customers are using the package (just think about how many people are using Microsoft Excel), the costs of development are spread among multiple companies, thus resulting in less expense for any given customer.

Consider a word processor. There is no need to reinvent the wheel, and create a word processor from scratch. The off-the-shelf word processor has all of the features you need, but with so many people using the product, the cost of it is relatively low. Even though there are some features that you may never use, they are easy to ignore, and the price is low enough that you still receive significant benefit relative to the cost.

Another benefit to consider is that the overall quality of the package may be better. Unless you are the first customer to purchase the system, odds are good that many of the bugs have been worked out before you ever acquire the product. Further, because the package is intended to appeal to a broader audience, it is also likely to include many more features than a custom-built system. There may well be features present that you just don't need, or want. On the other hand, do not be surprised if you find awesome features that you would never image existed.

One last thing to consider is that the procedures and workflow in the COTS system is different from what you currently use. While that may sound like a disadvantage at first, that would only be true of the current processes are better. This could be an opportunity to improve procedures by adopting those within the new system. It would not be the first time that I have seen a company implement much needed procedures and discipline after installing a professional COTS accounting system.

Middle Ground

In many cases, it may make sense to harness the best of both worlds. What that means in this case is making modifications/enhancements to a commercial package. Like the build decision, evaluation of this option should be done with a consultant very familiar with this approach. Some things to consider are:

• Making modifications means undertaking a development project, and all of the pitfalls mentioned above, apply here
• Not all packages can be easily modified or enhanced
• Modifications (and likely the original package) will probably not be supported by the package manufacturer
• When a new version of the package is available, the modifications will probably have to be recreated in the updated package software
• Features that modifications depended upon may not be available in newer versions of the package

An expert assessment is essential before pursuing this option. I am familiar with one company that spent a small fortune on a software system designed for wineries, and proceeded to modify it for use in a life science application. Years of work were needed to adapt the application with relatively simple additional functionality. If a consultant had assessed the package prior to its acquisition, the magnitude of the package's shortcomings would have been known, and perhaps a different decision would have been made.

On the other hand, a package that serves more as a framework, and is designed to be customized, can serve as a cost-saving and time-saving shortcut. An application such as Microsoft SharePoint provides tremendous functionality that eliminates the need for development, yet it can be customized if necessary to better fit a company's needs.

Pay Now or Pay Later

Whether you choose to build, buy, or customize should be an educated choice based on a careful evaluation of your needs, the cost of the various options, and the anticipated benefits of each. I have worked with many companies who are not very good at this potentially complex endeavor. Work with an experienced consultant, and avoid the nightmarish problems that can come from one bad initial decision.