Developing with Confidence
Over the course of my career, the way I develop software has gone through a lot of changes. Coming from Clipper, talking directly to flat-file xBase tables, then to Delphi, still talking to the database directly but this time to a "proper" database like Informix and SQL Server, and then to .NET Windows Forms, talking to SQL Server via web services.
But even the move from single tier to n-tier isn't the only change. There are fundamental differences in the way we approach a project now. In fact, there are differences every time we start a new project. Even in the past few years using .NET we've gone from using ADO.NET DataSets to using strongly typed DataSets, and from there to using an object model. We've gone from a bottom-up "model-driven" approach to a "test-driven" approach with NUnit and Moq. Before long we'll be looking at ORMs and code generation. So much change.
Every time we switch gears it's a good feeling. I feel like every change is a step in the right direction, that somehow we're more "correct" this time than last time.
However, the constant flux does mean one thing - it means I'm never 100% sure of myself. What if we're painting ourselves into a corner with this new project? What if tomorrow we find a better way? Should we be taking the time to learn ORMs now or should we just get this project done and look at it next time?
For me, software development is constantly having a conversation with two little characters sitting on my shoulder. One is the pragmatic devil, saying, "Get it working! Ship it! Forget about elegant code or new technologies!" The other is the dogmatic angel, saying, "Make it maintainable! Don't code that - use code generation! Declarative, not imperative! Handle those exceptions! Test first!" etc etc.
Does anyone else feel this way? Is software development a constant battle with your conscience? Or are you 100% confident in your methodologies? One way to stay confident is to not upgrade ever. I know people who develop applications in MS Access and have no reason to move forward - they're making functional, income-generating, single-tiered applications and they're happy. That's not how my brain works, though - I want to continue moving forward.
So who's with me? Who else feels a nagging sense of self-doubt every time they start a new project? It's a good thing, right?
# Trackback from Community Blogs on 4/05/2008 9:39 AM
# Trackback from Jason Haley on 5/05/2008 2:28 PM
# Trackback from Scott Muc on 5/05/2008 4:35 PM
# Trackback from DotNetKicks.com on 7/05/2008 3:40 AM
Comments
# Dave Burke
29/04/2008 8:58 PM
Well said, Mab. It's like "don't get too confident in your methodologies (and expertise) because you have to abandon them and start again in 6 months (and feel stupid.)" I'm overstating it, of course, but definitely a dichotomy is at play.
# mabster
29/04/2008 9:04 PM
I'm glad someone else feels the same way, Dave! I needed to vent a bit, but hopefully this'll make others realise that it's ok to feel like this.
# Nigel Spencer
29/04/2008 9:31 PM
Great post Mabster. Yep - I think its a good thing. On a project of any reasonable size you've got to draw a line at some point, pick your technologies and realise that by the end of the project:
1) You will have made at least one wrong pick
2) At least one technology pick will have been made obsolete
(Hmm... now you've got me worried - maybe that's just my projects!?)
Regardless, I like to think that its the continuous striving to improve your techniques and toolkit that make the job as enjoyable as it is. Like you point out though, its the counter-balancing "doing things well" with "getting things done".
(P.S. I thought that Donald Knuth's comments from his interview posted at codebetter.com/.../knuth-wow.aspx were certainly worth pausing to consider. Even if just to re-affirm "are we really improving?".)
# mabster
29/04/2008 9:48 PM
Hi Nigel,
Yes, I read the Knuth article earlier this evening. Some of what Knuth says is worth considering, but some of the comments (particularly that first one from Chad Myers) are just as insightful.
This post might just be a call to arms! Let's celebrate our doubts! Uncertainty FTW!!!
# Jason Haley
5/05/2008 1:36 AM
Great post. I have to agree and frankly I feel like no matter what I choose, I'm always 'behind' on what is 'probably' the 'right' choice ... sucks not being all knowing ;)
One thing I've been thinking about for awhile is: How can we refine and understand the new stuff faster?
Seems a lot of new stuff these days isn't just a small improvement to existing things but completely new frameworks and processes that provide still only provide the 80/20 rule (80% of the functionality you need is there fast - but to get the other 20% you're really going to have to struggle).
My current thought, which keeps be behind the curve, is to go with the pragmatic devil - but keep it simple and easy to maintain (without someone having to know the beta/ctp/latest version of stuff) ... still trying to find away out of this one ...
# mabster
5/05/2008 9:33 AM
You're so right about the 80/20 rule, Jason. Even the whiz-bang stuff like LINQ to SQL feels like it'll only get you so far. For example, in our latest project we've been trying to take a test-driven approach with as much test coverage as we can, and mocking the stuff that isn't being tested. We tried doing that with LINQ to SQL but it was way easier to do it with "plain old" ADO.NET.
I think you've hit the nail on the head - take a pragmatic approach but build in such a way that you can swap out bits later on without impacting on the overall architecture. That's served me well in past projects where I'm just now trying to rip out DataSets and introduce a proper object model.
# Poo
6/05/2008 9:32 PM
I sometime feel like I am Matt's pragmatic devil!
Remember that old programming joke, the hello world app done by a novice, intermediate and professional programmer where it gets more and more conplicated...to me sometimes it feels like we’re using a sledge hammer to hang a picture on the wall, the users couldn’t give a toss what’s happening behind the scenes, all they want is a functioning app.
Of course there's a certain amount of work that needs to be done to give them an app that will continue to function.
There’s a balance somewhere in the technology mix of functionality, time and maintainability... they rank in that order (most important to least) for me.
# mabster
6/05/2008 10:30 PM
Treating maintainability as a secondary concern is fine if you're writing small applications that you can simply rewrite when a new feature or fundamental change needs to be introduced, but that sort of approach is becoming less and less feasible.
After spending the bulk of my career maintaining other people's code, writing code that others can understand is forefront in my mind. Heck, you've been there Pete - you've had to inherit code from me! Had we been designing our applications then as we are now, your job would've been far easier.
# Michael Kimsal
14/05/2008 9:04 AM
@mabster - re: maintaining other peoples' code - documentation is a primary issue for myself these days as well. I don't always get it right, but I try to document the code well (comments) or write external documentation (large scale or just README files) or some combination to let the next person know (and there WILL be a next person!) what the heck went on, what I was thinking, and why I made the changes I did. I've done this enough now that I'm pretty confident it'll be appreciated by the next person too - I didn't previously believe that.
# mabster
14/05/2008 10:37 AM
Hi Michael,
Yes, documentation helps. I'm being won over by the "code should be self-documenting" argument (well-named methods etc) but comments should definitely be included to explain the "why" of something rather than the "what".
# Joe Reddy
6/06/2008 1:57 AM
I know exactly how you feel, and as a direct result I am constantly reading books.
I think the best we can do is work to understand the benefits of each new thing whether it is an Agile methodology, LINQ, nUnit, or TDD, etc, etc. Though something might have great benefit to one developer it may have none for the next. When a developer is trying to convince me to use LINQ or nHibernate or some other religious artifact I make them clearly state how I will benefit. They need to show me my pain before I start putting Band-Aids on freckles.
With maintainability high on my list, I approach everything I read about with a question...and how does this make my code easier to understand, change, extend, bug fix...???
I would go so far as to say that only a fool is 100% comfortable with the current way they are doing things.