Archive for the ‘Musings’ Category
I haven’t had a chance to use the new touch features of Windows 8, but even so I like it so far.
My main “likes” are the speed improvements. It boots up way faster, it seems to run every app I use faster and IE10 is way faster.
So, I’m happy with it.
I’ve gotten used to the Start Screen rather than the Start Menu, although I would like to be able to use the old Start Menu from the Desktop. When I eventually get a touch screen I’ll probably stop complaining about that.
Another sign that Win 8 will succeed is that a co-worker of mine bought an All-In-One Win 8 computer with touch for his computer-illiterate father and his dad immediately started using it and figured it all out with almost no help.
So for us .NET, MS development types, this all bodes well.
I really like Windows 8. But I’m just a lowly developer who uses a computer all day long so I’m not an average user and my opinion on the success or failure potential for Windows 8 doesn’t really count for much.
But this morning I had confirmation from an unbiased source that Windows 8 will be an enormous success.
This morning, my wife, who has NEVER EVER praised a piece of software, never mind an operating system, said, “I love Windows 8.”
I almost choked on my mouthful of breakfast and it took me several minutes to recover from the shock. All I ever got from her before this were complaints that “Yahoo mail is slow” or “Facebook is slow” or “I can’t find my file in Microsoft.” But this morning she told me, “I love Windows 8. It’s so fast.”
And that’s also the main reason I like it – IT’S SO FAST. The Windows 8 machine my wife has been using is a machine that previously ran Windows 7, so it’s not new hardware that’s causing the improvement. I also installed it on a machine at work where I upgraded rather than running a fresh install and IT’S SO FAST on that machine too. So the speed improvement is not due to hardware or cleaning out the Registry.
So if my computer semi-literate wife “loves Windows 8” then there is no question it’s going to be a success.
What’s even more amazing is that because she actually likes the Windows 8 user experience, she is finally willing to have me show her how to do other things on the computer. So this weekend I showed her how to use OneNote and she started using it. Then she wanted me to show her how to customize the lock screen and she wanted a desktop theme installed. She NEVER EVER asked me for any of that before. In the past she used it for her email and Facebook and Netflix and that was it. Now she’s actually interested in learning more and using more. That is a feat I haven’t been able to achieve after years of trying and now, after only three weeks, Windows 8 has somehow gotten her interested in learning more about all aspects of the computer.
So, there you are. That is why Windows 8 will be a huge success.
Okay, so I did know what TDD was. I’ve read about it. I’ve (sort-of) tried it out. But this morning I was listening to a Hanselminute podcast about TDD and I finally got what it really is. It is NOT “Test” Driven Development. The tests are there only because we happen to use a unit testing tool to help us apply this method of software development.
It really should be called something like “Harness” Driven Development or “Wrapper” Driven Development because what we are doing is creating a software exercising harness to help us design and develop our applications.
The side-effect of having a bunch of unit-tests so we can have confidence in the correctness of our code and so we can quickly test later changes, is great, but it is a side-effect and not the purpose of TDD.
Example: I need view models for the customer related views in an ASP.NET MVC app. So, to figure out the design of how I’m going to do this, I create a class in my “test” project with a method containing the functionality to get one of these view models: I have it instantiate an object of the class that will have this responsibility and make a call to a method on the class that will return one of the view models I need. This is the first step of figuring out the class and the api it will have. Now I can continue with the other steps of TDD. What I am doing here is NOT testing. It is designing and developing in an interactive manner. It gives me a quick turnaround because I don’t have to fire up the entire application to see if what I just did works, I can run just that single “test”.
It’s not practical to rename TDD to something else because the term is so ubiquitous, but from now on I’m going to name my “test” project “DevWrappers” or “DesignWrappers” or something similar to help me keep in mind that I’m NOT testing, I’m developing.
And now I understand that the “Test” in TDD is a misnomer, I think I will be using it a lot more.
Don’t call it Software Engineering anymore, call it Software Experimentation, or at least that’s what Tom DeMarco seems to be saying in this IEEE Software article: Software Engineering: An Idea Whose Time Has Come and Gone?
Software development is and always will be somewhat experimental. The actual software construction isn’t necessarily experimental, but its conception is. And this is where our focus ought to be. It’s where our focus always ought to have been.
A pretty radical thing for one of the founders of modern Software Engineering to say. I sort of agree and sort of don’t agree. It all depends on what you mean by “experimental”.
For example, it has been a rare thing in my career to be asked to create the same system over and over again. Even when I worked on five sales systems for different business units of the same company, one after the other, there were more differences between the requirements than their were similarities. I managed to use the same database structures for all five applications but the UIs and business rules were radically different. But is “experimental” really the right word to use?
I think a better word is “craftsmanship”. Let me explain:
When you think about it, the oft used metaphor of building construction for software development is really not a very good fit. How many times has a builder had to rip out the second floor of an almost complete fifteen storey building and replace it with a radically different design? Probably never, but how often near the end of a software project has the customer suddenly change or added to the requirements and you’ve had to do the equivalent of ripping out the second floor?
Software is malleable. Bricks and reinforced concrete aren’t. if we need to find a metaphor then let’s look for a profession that works with a malleable medium.
Let’s try a commissioned painter: the customer tells him that they want a family portrait, he has painted such before, but these are different people with different requirements: they want to be painted under a tree and the lighting is completely different to what the painter usually has to work with. So he puts them under the tree, plays around with the lighting and takes some photos until he gets something that works. Now he plans how he is going to paint the picture, perhaps with a sketch or two and a few posed photographs, then he gets to work with his tools – paints, brushes, etc. – and he produces the requested painting. When it is almost finished the customer wants his pet dog added to the picture, so the painter scrapes off the paint from that section and paints in the mutt. Not a perfect metaphor but better, I think, than the engineering and experimental metaphors.
So I propose we call our profession “Software Craftsmanship” and compare ourselves with painters and other skilled artists who work in a maleable medium. What do you think?