Utah Code Camp and a Piece of Humble Pie

27 September 2010

Utah Code Camp Keynote Presentation Audience Utah Code Camp just wrapped up this weekend. It was great! From the 40 or so presentation submissions they culled it down to roughly 20. There were some really good presentations and above all a great atmosphere. It was great to meet some of the great community guys that do a tremendous job of putting on such wonderful events. Among them is the tremendously affable Pat Wright, the wise Craig Berntson, as well as the ever informative Nathan Zaugg.

A Conversation with David Starr

David Starr gave a very informative and interesting keynote address entitled Modern Software Development, the State of the Craft. In it he had a couple of zingers:

"Any process is better than no process, the trick is to actually do it."
"Billions of dollars have been made from big piles of crap."
"Agile Manifesto is not a business model."
"Clean while you cook."
"Save your rocket powered brain for your business domain."

Agree or not, those are some powerful statements!

During lunch, an abrupt yet informative conversation sprung up with the Keynote speaker while everyone was in line for pizza. I don't remember what I was asked, but it ran along the lines of what software development process I used to develop software. Among other things, my reply could be summarized by

"I'm an algorithms type guy."

David interjected with something along the lines of:

"Every time I hear a statement like that, what I hear is 'I'm too smart for that kind of stuff'."

During that mini shock-and-awe campaign of a statement, I knew immediately that what he was preaching was right. Often as software developers we pride ourselves so much on the technology of the thing that we ignore the business of it to the detriment of the project. He further commented that what we lack as software developers is exactly what would smooth over our relationship with the business side of things: proper communication. A simple change of vocabulary, David said, would go a long way towards cementing those relationships and ensuring a successful project.

An Example - Reports

One huge example of this exact disconnect is the afterthought of almost all software projects - reporting. We (at least me) often relegate this integral, if not critical, feature of almost ALL software to the back-burner. Without reporting, most software would be useless. Imagine if a business guy comes to you and says: "We need another report that has X!" What causes the roll of the eyes in this instance? What are the pain points involved in adding this new magical report? In the next couple of weeks/months I will try to show you how to make it easy to make these changes so that you can smile and say "I'd be happy to make that report! Is an hour or two too long to wait?"

Feel free to shoot me an email with the pain points involved in reporting so I can include them in some of the demos and tutorials!

Seth Juarez
Email: sethj@devexpress.com
Twitter: @SethJuarez

3 comment(s)
Kendall Miller

I've often joked about the value of Reporting Driven Development for business applications - if you can't design the reports then you aren't really ready to write the software.  In the end, some of the greatest value out of any system is the reports it can provide because they either directly influence business decisions or indicate the success of existing business systems.

I can recall many times where I was completely confident of the design of a system - we were collecting the data nicely, you could configure it, everything looked great.  Then we went to make one or two critical reports management wanted and discovered we didn't have a few pieces of data or it just wasn't possible to differentiate scenarios they needed to see broken out.  At that point these were expensive to fix..

Since then I've taken to working out the exact reports (the rules for each field, what format is the data, etc) before signing off on the database schema and gettin' dirty with implementation as a checkpoint that it really reflects the business goals.

27 September, 2010
Santosh Benjamin

@Kendall, Nice term "Reporting Driven Development" and true as well. We could save ourselves a lot of time if we did those things early on. Sometimes people tend to push that out saying they have SSRS or equivalent tool but they forget that the issue is whether those data fields are available or not. But then again, users reporting needs tend to be quite volatile (apart from the usual KPI bog-standard ones) so you could get bogged down in "reporting analysis paralysis"  if you're not careful. Maybe someone will come up with an "RDD" framework that examines your domainobjects and db for key fields !!

29 September, 2010
David Shannon

The short form of many discussion on this issue: "Input is the cost, reports are the benefit."

4 October, 2010

Please login or register to post comments.