Maybe Blogger's not so bad

Yesterday I submitted a post complaining about blogging with Blogger. I switched the host from Doteasy to Blogspot, and has resolved most of my issues. So maybe Blogger isn't that bad, but they could improve their support for FTP sites.

There is still some quirkiness though. For instance, I changed my feed setting from "full" to "short" expecting that my feed will carry the first paragraph or two of my posts. Instead the feed shows none of the post. I also can't figure out how to include comments on the main page. And the comments page is styled with Blogger's default color and font scheme.

I have also set my main page to hold seven days worth of posts, but I see that it goes back a month. There must be a setting that I am missing, because the QA of a site like Blogger can not possibly pass errors this obvious.

By the way. I have a new URL for my feed. For those of you who subscribe (both of you) please change the feed to: http://iambillmccann.blogspot.com/rss.xml

Blogger Frustrations

I have been using Blogger for about a year. Prior to using Blogger, I published my blog manually by typing html and updating links on the pages. Blogger has made publishing much easier, but there are some things I haven't had the time to figure out.

For instance, I don't know how to write a summary for RSS feeds. It was pretty easy using manual methods. I would simply copy the first couple of paragraphs of my post into atom.xml and I was done. Blogger, though, seems to post the entire article to my feed.

I also struggle with styling. My posting on "How Much Detail in Requirement", for example, switches to the "smallest" type size on the bullet list. I have manually adjusted it many times, but I can't get the text to match. I also struggle with the vertical spacing. Unfortunately, Blogger's WYSIWYG editor isn't all that. Maybe I'll switch to Google Docs for editing my posts.


I have trouble with my template too. I like the top of my blogger pages to match the style of my web site. Unfortunately, Blogger's styles clash with my stylesheet resulting in odd colors on my links. I can fix this manually, but I haven't found the time...so I look stupid instead.


The problem could be related to my host. I use Doteasy to host my blog and web site. Blogger supports richer layouts, but you have to host with Blog*Spot. I'm thinking of hosting with Blog*Spot and using links to connect my blog with my web site.

Of course I'm secretly hoping that someone reads this post and has quick and dirty solutions for my problems.

Are we dumbing down programming?

Her resume looked great. She was coming to us as a high end (price) developer. But as I listened to her describe an abstract class in response to my asking her about abstraction, I had to wonder; have we made it too easy to be a programmer?

It's true that abstraction is the most intangible concept of OOP. During my phone screens of candidates, though, I find myself wishing I had tipped them off. I will be asking about OOP. Go look up "object oriented programming" on wikipedia.

I generally blame our universities for this failure. OOP is largely conceptual, and should be introduced and reinforced by any Computer Science department worth their accreditation. Once in the workplace, software engineers rarely get the proper mentoring on solid coding habits.

We really can't lay blame entirely on universities and trade schools. No, much of the problem lies with the technologies we use to build applications. High on the list of offenders are Visual Basic, Visual Studio, Java, and .Net. Throw in HTML, XHTML, XML, and all the mark-up language derivatives. Then add in any of the web development tools like Cold Fusion and Flash. Of course the scripting languages, JavaScript, VBScript, and Perl virtually prevent solid coding practices.

My obsession with OOP stems from a very specific business need. I have to support ten software products with a very modest staff. The most basic way to accomplish this is by reducing the amount of code. An obvious way to reduce code is reusing code. Unfortunately I inherited a situation based on copy-and-paste code. After three years of fighting copy-and-paste habits, we still support multiple versions of code that perform the same task.

Many developers confuse using objects with OOP. Dropping a control onto a form does not constitute object oriented programming. In fact, there will be nothing reusable in the result. In addition, the automatically generated code written by the action of dropping the control is almost certainly unreadable. But then, many developers today don't even realize code is being generated.

So our tools have dumbed down programming skills. Especially for those developers who rely on the designers and tools built into their development environments (IDE). For me, I'd like to find an engineer or two who would love to create the next Visual Studio, instead of dragging controls from a toolbar like some pre-programmed automaton.

Small Company Blues

At dinner with a friend yesterday, he lamented about problems rolling out technology in a firm he is managing. Apparently his team misses their delivery dates; by a large amount. As he described his situation I felt like I was experiencing deja-vu.

His story in brief; he has four people maintaining his technology. These people are responsible for bringing clients online, handling technical problems, and building new capabilities. Projects are frequently months late. A core component of the system is constructed on an antiquated platform (Paradox) and only one individual has working knowledge of the code. And on and on.

This is a very common situation in technology firms managed by "non-technical" people. It is caused by the number one oversight of CEOs who have never worked with sourcecode. I even see it here, at my current firm. The problem is that there is little accounting for maintaining the product. The assumption being, when the product is delivered to the customer, its' developers are free to work on the next thing.This is a dangerous trap and I have seen many very intelligent executives fall in it. Inevitably, the development team becomes forced into choosing between support of the current product and construction of the next. That decision is a no-brainer, and construction of the next thing gets continually put on hold.The solution is fairly simple, but it is a bitter pill for developers. The team must be split, with one group providing support and the other working on the next thing. Of course no one want to be trapped providing full-time support. In my role, I have tempered this morale issue through job rotation. In the end it is necessary to prevent the continuous interruption of new development.

No Country for Old Men

I didn't see the movie. I read the book. Here's your warning: this blog is a spoiler for the story, so if you plan on seeing the movie, take a pass on this posting.

I finished No Country for Old Men with mixed feelings. Admittedly I found the story riveting, after all I could hardly put the book down once I had started it. Call me soft, though, I don't like when the bad guy wins.



It is fast paced with a riveting story line. The language is simple and boiled down to the basics. There are no flowery descriptions of peoples feelings or dramatic landscapes. Given that most scenes carry a fair amount of blood, this is a good thing. Characters aren't very deep or well developed, or maybe they just don't live long enough to get developed. It's a perfect story for a Coen brothers movie.



One more thing...the book would be easier to read if the dialog was surrounded by quotes. I don't see why a basic grammar rule would be flat out neglected.

How much detail in requirement?

I mentioned that over the course of twenty five plus years, I've tried nearly every development process you can name. In my experience, I find that projects tend to break down at the start. Yep. Failure is built in into the project during the requirements stage.

Requirements are written in varying detail. During my tenure with DoubleClick in 2000, we had initiated a project for the advertiser side of our industry. In my ten months with the firm, the document was never finished. The last time I saw it, it exceeded 300 pages. We appointed a steering committee to oversee the project and they would debate the document endlessly. And the result of the debate? A bigger document.

In short, the entire exercise was useless. In parallel to the requirements fiasco, an engineering team was already well into the project, virtually ignoring the written requirements. I have seen this practice of over doing requirements at several firms, including DoubleClick, Information Builders, and Ameritech. In most cases the resulting document is either too large to be useful, or is ignored by the developers.

Of course the reverse is often true too. In fact, the reverse is probably much more frequent. For example, my team recently received the following requirement for a component of a new product:

"Management reports – using multiple selection criteria, produce reports that track turnaround time and other metrics."

Thing about the number of questions that are opened by this simple one sentence requirement. What reports? How many? What columns, rows, sorting, totals? What selection criteria? What is turnaround time? What other metrics? In fact, this requirement tells a developer nothing. There is absolutely nothing the system architect can do except return to the business analyst and ask questions. To make matters worse, the business analyst believe he has provided a useful document.

Then there are requirements that mask the business need in technical details. Some might read something like:

"Add a column to the x table to hold a flag. Display the flag on the detail page. When transactions are received for records with the flag set to 0, ignore the transaction."

This might look like the appropriate middle ground, between the extreme examples illustrated earlier. But it's not. The business analyst has interpreted the business requirement and supplied a solution. Although many business analysts fancy themselves as system architects, I have yet to meet one who is better than the engineer. What is the requirements above? A method of disabling master records? A method to manually override batch operations?

The plain fact is it hard to write useful requirements. And a project with poor requirements is destined for delays and cost overruns. If you wish to keep your requirements meaningful, stick to the following rules of thumb:

• Describe the business need (not the technical solution)
• Keep it brief (it a single capability takes more than a couple pages then your too verbose)
• Describe everything (if there are four reports, describe each in with their own requirement)

When you avoid the pitfalls from poor requirements, your project will be constructed on a solid foundation. The chances of success are will be far greater.

More reading for fun

I read two books recently and they were both pretty good. The first is American Creation and the other is A Tale of Two Cities. Yes the time period is similar in both books, but that was merely a coincidence. I don't have an express interest in 18th century history.

American Creation introduced me to stories about our history that I found intriguing. I had held a belief that the founders were mostly united through a common enemy and purpose. That belief didn't make sense and the stories in American Creation highlight the difference of opinions and approaches that form the basis of our nation. Themes trumpeted by Washington (strong central government) and Jefferson (sovereignty of the states) echo in politics today.

I found A Tale of Two Cities surprisingly good. Sure, I was familiar with the opening page..."the best of times...the worst of times." I had even attempted reading it when I was younger. This time, though, the story had me riveted. Yes, you have to adjust to the flowery language of Charles Dickens, but the story is very suspenseful. Plus there is plenty of violence, intrigue, and romance.

What Were They Thinking?

Here's a book that you can pass on. What Were They Thinking is management dribble that either states the obvious or makes poor conclusion. I've seen the reviews on Amazon and must admit that I disagree. In fact, I think this book is dumb and was very disappointed. I picked the book up based on a magazine review. I didn't feel the anecdotal examples sited by the author truly supported his conclusions. I could easily come up with examples of my own that would refute his claims.

SDLC

Agile. Waterfall. CMM. Spiral. Test Driven. Blah, blah, blah. I believe I have researched a dozen software development methodology and have tried many of them in practice. Unfortunately I have yet to find one that works. One that combines rapid development with high quality and delivers projects within their targeted timeframes.

I suppose if it was easy, then there wouldn't be entire shelves at Barnes and Noble devoted to it. It it was easy, then everyone would deliver with great success. I'm becoming convinced that no single methodology is portable through development shops. And that successful SDLC (System Development Life Cycle) is a painful trial-and-error process that adopts aspects of several disciplines.

I've tried the standard waterfall. It generally has two problems. First, it is nearly impossible to completely define all the functions of a system prior to providing any code. And second it is very difficult to prevent scope creep.

In the first case, a business analyst has to be imaginative enough to define all aspects of the system. Then she must be able to accurately write these into requirements that are understandable by developers. I've never seen this done well. When overdone, the volumes of requirements become impossible of shift through, when underdone entire aspects of logic are left undocumented.

Waterfall project tend to be very long, running months or even years. This causes the inevitable panic when business analysts realize a pet feature is not included. The panic often results in scope creep, which in turn causes the project to run longer.

We've tried incremental methodologies, such as Agile too. Ok, you say, Agile isn't a methodology, but a class of methodologies. But does anyone really implement strict Extreme or Scrum or EVO?

Regardless, Agile methods have their built-in weakness too. For instance, how do you know when you are done? Or, as in the case with my current projects, resources get diverted into new critical projects, leaving others unfinished.

When it's all said and done, some hybrid method seems to work best. Concrete, but overlapping, phases are necessary for project management. Within each phase, iterative cycles with feedback have great benefit. Who knows, maybe I'll develop my own methodology, and then write a book (that no one will read).

Headhunters

Has anyone noticed that recruiters work harder when you're hiring than when you are looking?