Software development is an insane business. Truly. The definition of insanity(as most know) is repeating the same thing over and over and expecting a different result. And despite years and years of learning and hammering to make things “modular”, “decoupled”, “services” and “layered” developers still come in and continue to tightly couple applications to the point that I feel like I’m staring at a giant obelisk. There’s no way to do anything with it beyond take it for what it is and start building another.
I feel like console applications are a way to prevent some of this especially in the phase of building domain, data and business layers. In my experience developers get wrapped up in things like MVC, Silverlight, ASP.NET, WPF, Mobile and whatever the end goal interface is. They want to go from bytes to complete functionality and press a button so badly that they rush through everything.
Writing a console application is a chore to most of the undisciplined. It takes focus away from the end result and allows you to focus on the business of what you’re writing. It stops you from hanging up on some pointless JQuery subtleties for days when you’re supposed to be building an appropriate business logic functionality. Hell short of standing behind a developer II with a gun I can’t get them to actually digest the purpose of a View Model because going around it is quicker and allows you to close a task in 10 hours when it’s scheduled for 40.
When a person who’s written several more applications to you in the specific enterprise you’re in schedules tasks for 40 hours and you finish them in 10 you should think perhaps you’ve worked with a bit too much haste.
I came to the conclusion to write console applications for anything not so long ago after an interview in 2010. A solutions architect came in to interview me and flipped a laptop open and asked me to write some functionality. At that point I NEVER wrote console applications however I figured it out and he rather enjoyed the result. I got to know this guy a little better and found that he wrote console applications for everything being that he worked in integrations and had zero care for interfaces. It wasn’t important as he only wrote services. I decided to try my hand at this on return rather than trying to bolt up functionality clumsily to whatever flavor of interface technology we were focusing on at the time.
The quality of code and the bug rates were noticeable to say the least. Domain errors were reduced, business logic bugs were identified sooner and tests were run cleanly before a single fancy Telerik control hit a page. There was no scrambling later and reproducing code in multiple places because you accidentally added business logic to view models in a Silverlight project that you needed in an export service later. Further we were able to quickly produce those fancy client applications because we didn’t have to perform changes to a domain that crippled some aspect of your MVC application because you worked directly with your domain objects.
Kind of all over the place in this rant aren’t I? The point is that when you use a console application to perform taste tests on your products you don’t make near the mess. All the great products out there by Microsoft, 3rd party vendors and open source products are so enticing that they take focus away from creating quality software. I think that if you’re in an environment with a lot of developer freedom you should go console application first while creating the ground work of an application. It’s in my opinion the best way to stay focused on the right kind of interfaces and create sound software.
I’ll probably read this next week and disagree with a bit of it but hey take it for what it is. A rant based on my experience.
no comment untill now