Utah Code Camp and a Piece of Humble Pie

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

Free DevExpress Products – Get Your Copy Today