I’m a .NET developer working for the Trondheim-based company Sentinel Software, where we're building the next generation sales-support tool for car dealers.
I started out in this geekie world as a database/web developer on Microsoft SQL Server 2000 and classic ASP. And even though I still enjoy programming intricate joins in T-SQL, since I was introduced to .NET and C# in 2001 I have never missed classic ASP.
In my early days as a .NET-developer I mainly worked on ASP.NET WebForms. Later I moved over on the desktop and starting building WinForms, but still with some ASP.NET work occasionally. Since late 2007 I've been fortunate enough to work on WPF and I must say that I'm immensely pleased with this framework and hopefully I’m all done with WinForms.
Strongly influenced by my former colleague Pål Fossmo I’ve also developed a strong feeling for Test Driven Development. What I really enjoy about TDD is the confidence that testing gives me. It makes me sleep better at night knowing that the code I wrote today has been proven to work and I didn’t mess up any other parts of the application writing it.
Closely related to the awakening experience of testable code is my interest in design patterns and beautiful code. These three pillars – testable, pattern based, well-written code – are what I consider the very core of developing good, maintainable software. I believe that one of my main responsibilities as a developer is to make whatever code I write understandable and thereby maintainable to the guy or gal next to me. Because when I move on to the next project/job, (s)he is the one who’s going to maintain and build on to the code I just left behind. Taking pride in making that an as easy job as possible is always my number one priority.
I was awarded an Microsoft MVP in C# in July 2014.
2 comments:
Hei Kjetil!
I presume, based on your choice of language, that your blog is aimed at an English-speaking audience, so I'll follow your lead.
This post being the required "Who am I?" page of your site means one could ask who I am to comment. But you do speak of a few things that are currently very trendy topics in our craft (trade? art?) and my comments relate to these.
First, I think I've undergone a similar "awakening" as you have with regards to SCRUM/DFT (not quite the same yet related concepts, so I'll permit myself to lump them together here), design patterns, and "beautiful code", a rather fuzzier concept I would claim.
However, I feel that there is one other aspect of software design that receives nowhere near the attention that it deserves. To me, it is "the elephant in the room".
Ponder this: What is the root cause of complexity in software? There are many proximate causes to do with things like "the web was designed to be a gigantic library of interlinked documents, not to be an application platform" or interoperability problems or versioning issues. But what is the ultimate cause, the one that will never go away? The answer is so banal as to seem a bit stupid at first: The world is a complicated place. In slightly more academical terms, the complexity stems from the domain - whatever it is the application deals with is itself complex.
So why then does almost nobody discuss domain modeling? Why is there so little talk about what techniques we can use to find elegant expressions of the important concepts involved in a domain?
In many projects, particularly "expert systems" where the software needs to capture a lot of domain knowledge, the domain model is the heart of the system. It can serve as an expression of an entire development teams knowledge and provide a precisely defined terminology that domain experts and programmers share - and that is used consistently in documentation and code.
If this peaked your interest at all, head over, for a great book, to Amazon.com (http://tinyurl.com/yf4hb27 for your convenience) and read the excerpt, then decide for yourself if you think it's worth reading. Personally, I think it is well written and providing lots of practical applicable technique, not just "philosophy".
On a side note: Such "philosophy" (or sometimes dogma) is all too often all I get from postings about how to make software. For example, it might be good advice to recommend the use of a SCRUM process. I believe the premise of SCRUM is valid: These things are too complex to realistically do in a monolithic "plan first, then build" way. Feedback is necessary, hence the iterative approach. But at the same time there is surely something to the logic that you can't do much, and especially not do it well, if you have neither decided what to do nor given thought to how you'll do it. So to me, it would be far more valuable to see someone say something enlightning about how to determine the exact parameters of the process than just another (of thousands) of general recommendations of the approach. How do we decide how long the iterations ("sprints" in SCRUM terms) should last? Who should be included? The customers? Selected users? Marketing? Or just the domain experts and programmers?
Marketing, since I have the chance: I'm currently looking for a job in Norway, should someone who reads this be hiring or know of someone who is. I imagine I'd most like to move to Kristiansand, Bodø, Trondheim or Oslo, but if the opportunity is sufficiently interesting and located in or near civilization I'd like to hear about it. :)
Oh, my. What a great comment. Feels like your comment deserves a blog post by its own :)
The book you refer to, “Domain Driven Design – Tackling Complexity in the Heart of Software” by Eric Evans, is one of my all time favorites. I read it for the first time in early 2008 and I’ve read it again several times after that. It’s a book that every software craftsman should read. Even if you’re not going to follow the architectural design in DDD, this book is just packed with so many good advices and life experience that you simply cannot grasp it all by the first read. It’s a inexhaustible source of software wisdom.
In my experience, DDD by itself is however not the whole answer to tackling complexity. There never is one solution the complexity we face in software. “There’s no silver bullet” as Fred Brooks states in “The Mythical Man-Month”. But my current belief is that mixing domain driven design with agile practices like short iterations and behavior and test-driven development, is one of the better ways to tackle complexity.
But is that enough? No, I don’t think so. The code we write is written once, but it will (hopefully) be read 10 or maybe 100 times. So you need to have strong focus on the readability of the code. “Clean Code” by Robert C. Martin has some really good tips and lots of practical insight on making code more readable. But then again; “readable code” is subjective. What I find readable might not make much sense to you and vice versa. So the team needs to have a common agreement upon coding standards and a strong focus on making code as easy to understand as possible. Practicing code reviews, pair programming and coding dojos would help leveraging a common team practice.
After all, code that’s poorly written and hard to read is hard to change no matter how many unit tests you throw around it.
So, no; still haven’t found no silver bullet, but I’ll keep looking :)
Post a Comment