CogNerd

Someone recently asked me to come up with one reason software projects failed. Although this is more generally about software development, many of the things are unrelated to platform.

Here’s what I wrote:

Un-unified vision across all participants.

In order to make something, you first have to see it in your minds-eye. Not only the developer, but everyone involved or affected by the system … so-called stakeholders. It is common that due to workloads, personality differences, inexperience, unwillingness to deep dive on what needs to be done and more, people will not cover parts of what is needed.

There is often a cultural clash between developers and business people who need the system. The developers need specific, deep details about the business process that is being implemented, and the business person is either too busy, unsure (an unwilling to say so), annoyed by the persistant questioning, or unaware of the level of detail that is needed to eliminate the ambiguity.

Generally, in this party of 2, someone has to reach over into the others’ discipline in order to understand the realities and tradeoffs necessary. If neither person steps up to that task, then communication problems will occur and the software will suffer, often fatally.

Creating software systems is about as flexible as building houses. Once the concrete is poured, the walls are up, the number of floors decided and the layout commited-to (in wood), any changes after that become hugely expensive, involve discarding previous work, compromising work that remains, confusing participants and more.

The secret to good software projects is to spend the time and energy to get to the bottom of the details. I have evolved over many years to typically spend much time with the business people to learn their business at a level of a full-staff member. Then, I can look for gaps between the two visions, articulate them to the business people, and wrestle with the discrepancies and the challenges that these open issues create within the software design. This needs to be done methodically throughout the software and business application.

I recently got nipped by using a boolean in Oracle. It turns out there is no Boolean field type, but you can use them within PL/SQL. I have an application where I’ve coded a function to determine whether or not a day falls on a weekend (is_weekend) and coded it to return a boolean. While looking into other problems, I was trying to include a call to the function in some diagnostic SQL statements and really struggled to get it working. If I had the option of recoding, I’d return a Y/N from the function enabling me the complete flexibility of using the output as I see fit.

Live and Learn

Whenever you get a chance to affect design, always aim for explicit designs.
I like to think in terms of principles, and this one is a super-important architecture-level pillar.

Because this is a principle, it is more difficult to learn without specific examples.

This principle applies throughout IT, but database design is a good platform to use to explain. If you need to track whether or not something happened, in system design, you will best be served by having a field in the database indicating the same exact thing you are attempting to track. Frequently, I’ve seen a design where to determine if that thing has happened, you need to sook at two other fields and apply some logical rule. In effect, the stste of the thing you are looking to track need to be implied from other data.

Both methods have their costs. Implied puts to onus on the consumer of the data. Explicit put it on the creator of the data.

Implicit has (IMHO) more exposure to bugs as changes to the underlying items may be made that unintentionally affect the logic of the implied item. With explicit, the error has to be made in the module that works with the specific field.

Basically, being explicit makes the design more one-to-one, here is an item that tracks what I want, here is the code that manages that item, here is a logical change to that rule, so change that code that changes that field…. And so on. The direct nature make it easier to understand the impacts and find and fix bugs without hugely complex redesigns.

In IT, there are some ever-lasting priciples. Yes, believe it or not, this rapidly-changing business does have some things that are barely changing.
One that I have observed, is that you will always benefit from knowing as much about your data as possible.

Specifically, you need to understand the relationships between data and WHY the relationship exists … I mean what in the business requires this relationship.

You need to understand when and where there are special cases in the data and how they are to be addressed.

You need to understand how clean the data is.

You need to understand the time volitility of the data and whether or not it has an impact on your reports.

In short, the job of drawing useful information from data is more than dragging and dropping fields onto a report. Nothing in IT is as easy as many people want it to be.
You can learn the names of a few fields quickly, but when, why and what the limitations of the data is harder to learn and frankly makes you more valuable to any organization.
One piece of advice. Spend 3 times longer learning about your data at the beginning of a project and it will pay huge rewards.

You can test several different things when configuring Cognos 8. For example, you can test your database login, email server login, the log file server, and your Security provider(s). All you need to do is to right-click on an item and test will show as an option.

It is all too common that you have a situation where you need to control the order that queries occur. For several years, I had wondered how to do it exactly.

Ideally, Cognos would have a property called Query order, and whether or not a query could be run in parallel or not. Well they don’t.

You do have the ability to control the query order, and, it is determined by rendering order. You might think it could be determined by the order of appearance of queries in the query screen, but that is not the case. Instead, how you use the queries will determine the order of query execution. For example, if you have 3 lists in your report, the query associated with the top list will be executed first, and the second list second.

Things get really interesting and useful when you need to run stored procedures as part of running a report. I’ll make a futher post about this.

If you will need to align multiple lists or columns of a table wthing your report, you need to spend significant thinking time before you begin.

The auto-sizing capability of HTML is a great thing, BUT, strictly talking about HTML, when you have data in one column of a table that needs to align with data in another table, same column, you may end up extremely frustrated.

The problem is that HTML will tend to size things as you ask, but will break the restrictions based on actual contents of a cell. So even though you size a column to either a percentage or fixed space, It may grow in size and screw up your synchronization of multiple tables column sizing.

The generally best approach to this nasty situation is to use one table (In Cognos 8, a list ends up as a table). This way, as a column grows to accomodate the data within it, all lower columns also grow to the same size.

All developers love hooks. Here’s one for ReportNet and Cognos 8

Occasionally, you may want your BI tool to write data to a database. How can you do this?

For example, what if you had a report requirement to show all data that has been added to the DB since the last time the report was run?

In Framework Manager, you can model a stored procedure as a query subject.

Although the reporting tool cannot directly write to a database, you can write to a table from the stored procedure.

You will need to model the stored procedure as a query subject. I recommend the procedure returning a single column and single row of static data. Once you model this Query Subject, you need to include this static field in your report. Having it there will call the stored procedure when the report is executed and the procedure can do anything to the database that you would like it to do.

To finish my example, your stored procedure can merely insert the current time to a logging table. The report can have a filter allowing data only since the max date from the logging table and the report will only show data created after the last time the report was run.

Either the splash screen, the report dialog box, the main reporting window or another startup screen in Report Studio will be stopped by popup blockers. Don’e let it throw you.

You will sometimes get unexpected prompts in Cognos ReportNet and Cognos 8. These prompts are typically being auto-generated by the reporting engine.

There are several modes that cause the unexpected prompts, but excluding ones that are within the model for the moment, the problem is typically something having to do with filters.

First, if you have a parameter in a filter or elsewhere that is not being populated, the reporting engine will auto-generate a prompt for you. Typically, this happens when you misname a parameter, or delete a prompt without deleting the related filter. Parameters are typically populated by prompts but can also be populated from the URL, or, drill-through or the administrative interface as well.

Beginners will run the prompt wizard and when things go wrong, merely delete the prompt. Report Studio does not automatically delete the related filter; just deleting the prompt leaves the parameterized filter in place. Next time you run the report, the engine will find an “unsatisfied” parameter and then generate a prompt on your behalf.

The key to fixing this problem is to remember that if you delete a prompt, it is YOUR responsibility to delete the associated filter.

The second way to have an unpopulated parameter is if you manually edit a filter and change the name of the parameter, or even the case of the parameter. As parameter names are case sensitive, merely changing one letter to a lower case will cause the auto-generate prompt to happen. To fix this problem, there is a property of the prompt called parameter, this is the parameter that will be populated by the prompt, merely open the property and choose the proper parameter from the dropdown.

Another completely different mode of auto prompt generation is the usage property of a filter. If you want to have a prompt on the same page as the report, it is essential that you set the filter’s usage property to “optional”. An optional filter means, if no parameter value is supplied, apply no filter. The catch-22 is that if you have a prompt on the same page as a report and the filter is required, how can you see the first page of the report containing the prompt, if no value is supplied? Fix this problem by changing the filters’ usage property to optional.