January 17, 2007
Shaking Things Up
We talk a lot about our experiences in this column about our agile software development practice...so much so, that perhaps it sounds a little self-serving at times. After all, we're heavily invested in agile methodology. So here's a link to another developer's (Russ Nemhauser's) blog...a developer who joined an agile team at a Large Software Company Somewhere in the State of Washington. His background was in BUFD (big up-front design) and he therefore approached this Scrum project (in .NET) with a great deal of skepticism. Read about his conversion here. He also gives an example of test-driven development and talks about why he's now a believer...so much so that he's uncomfortable writing code before he writes the test(s)....and how (at least in this example) it was a time saver. (YMMV, of course.)
An interesting idea:
This doesn't solve the problem of some clients requiring large functional specification documents, but it does offer at least one potential change to the way they're written: the functional specification can be written AFTER the majority of functionality has been developed and delivered. This is a huge step toward an accurate specification and it also drastically reduces the amount of time it takes to write the document.
October 30, 2006
Heartland Developer Conference 2006
Bud Wheeler just sent me this excellent overview of HDC 06. Bud is a seasoned developer with Visionpace doing custom software development in Kansas City, with a focus on Microsoft technologies and agile software processes. Thanks Bud!
I just returned from the Heartland Developer Conference (HDC06) held in Omaha Nebraska. If you aren’t aware of this conference I strongly suggest that you look into it next year. It has to be the best value of any conference I have ever attended. It was a well organized and top notch production.
As I understand it this is a roving conference and has been held in a different city every year. This year the conference was held at the Qwest Center which is a great facility that easily handled the needs of vendors and attendees. There were over 500 developers at this years sold out event. Look for information about HDC07 to be out in December or January.
The conference was split into three tracks labeled Think It, Server It and Store It. I found myself in the Serve It track for most of the conference. Of all the sessions I attended the things that really excited me were XAML and ATLAS/AJAX. These technologies look to be very cool and I am going to spend some time over the next couple months playing with them.
The great thing about a conference like this is that the excitement is contagious. The speakers are evangelists for the technologies they present and it is hard not to absorb some of that excitement. What a great way to recharge the ol’ batteries. We too often get caught up in the daily grind of development. It is essential to take a step back and look at the bigger picture. As developers it is our responsibility to not only provide solutions for our customers current business problems but also to look at the future business needs. Developer training is a big part of that and I encourage every developer to spend some time looking beyond their current tasks. For me the chance to talk to other developers is as interesting as the sessions. The opportunity to discuss how they are solving problems is a great way to pick up new ideas.
To paraphrase one of the speakers, software developers are the only professionals that are trying to solve constantly changing problems with a constantly changing set of tools. How are you going to keep up with that if you are not doing something to educate yourself?
March 29, 2006
When the story doesn’t fit
On a recent .NET consulting project in Kansas City, where we were doing software development and agile project management coaching, the team was struggling with sizing our user stories to fit our iterations.
Invariably during our projects we find that some of the user stories we came up with during the initial story workshop don’t really fit in the project development as written. Sometimes they are too large for the time allotted and/or have some high priority tasks and some not so high priority tasks. Other times we’ve learned so much about the project, the initial story doesn’t encompass all the facets it should. The question is what to do with these stories. Should the entire story be tasked out and carried over to the next iteration, should only the necessary tasks be focused on, and the story carried over, or should the story be broken down into smaller stories?
The answer, like a lot of answers when following an agile approach is; it depends. One can make an argument for any of the scenarios listed. Since I’m the kind of person that has a ‘I want to show progress on the burn down’ perspective, I prefer to break the story into smaller stories that ‘slice the cake’. (The stories aren’t all user interface or all back end processing. Rather they have some user interface, some middle tier logic and some back end processing.) What’s important is to capture the stories based on the current understanding, scope them in an appropriate size as much as possible so they don’t have to be broken down again later, and make sure that nothing falls through the cracks.
Once a story is broken into new stories the next thing to consider is how to forecast the new stories. Often times there is the desire to say that since the original story was forecast as a five points, and since we broke it into three new stories, one story that is three points, a second story that is one point, the remaining story must also be one point (5=3+1+1). Don’t do this. Another pitfall is for the team to say “When we started these stories would have all been threes, but since we have a better idea about what we’re doing, they all look like one’s now.” The key is to forecast each of the resulting stories independently and triangulate them against the existing stories for the project, making sure they are put in the right bucket.
The take away is to make sure the user stories reflect what you are doing in an iteration rather than trying to make the iteration fit the stories defined. If this means that some stories need to be removed and rewritten, do it. Just pay attention to the stories that are created to make sure they will fit in the future and that you don’t lose anything in the transition. Also remember that the forecasting for the stories follows the same triangulation used in the original story workshop.
March 24, 2006
.Net and C# coming to the Mac?!?
Wow, this could be huge ... if it stays on track, of course. This actually hits pretty close to home. When we were looking at the next version of Qumana we knew we needed a PC and Mac version. Then, the only viable option was something based on Mozilla (sounds great, lousy documentation) or Java (well supported, but rather sluggish). Rumours and whispers of something like this were tempting but far too vaporware to base a real development plan on.
The big question is, will this matter? Will a lot more apps be written so that Macs can use them? That's tough. As much as this is touted as a "cross-platform solution" I know from the Java experience, you will have to tweak for Mac and PC. It will come down to ... is there a large enough user base to warrant the additional development?
I guess we'll just have to wait and see.
Oh, the image above? That's a test widget in this new programming tool ... in Firefox ... (credit to Adam Kinney)
Software as a Service (SaaS) ... haven't we done this before?
Not to be a curmudgeon, but I don't get the sudden hype around SaaS. I like my hosted web services as much as anyone, but I find this smells a bit like over-hype. As good as a SaaS service might be, and with AJAX and better bandwidth making the apps extremely rich, these applications are still vulnerable to outages, crashes, and when you're offline ... so is access to your data.
But ... what do you think?
February 22, 2006
Battle brewing over C++, .NET, and standards
As C++ is before the Ecma for standardization, there is a little problem. Seems that tying it to the Common Language Infrastructure (CLI) ties it too closely to .NET WebProNews continues ...
There seems to be a C++ schism going right now as the Ecma consortium works out standards for the widespread programming language. The specification will bind C++ to the Common Language Infrastructure (CLI). This presents a problem for some because it ties the language a little too closely to .NET.
The basis of the controversy comes from the fact that .NET Framework is an integral part of the CLI standard. As ZDNet pointed out, it also paved the way for Microsoft to say that .NET was standards-compliant. They also pointed out one of the major strengths of .NET is the ability to write in a variety of languages. This isn't a bad thing.
But, ZDNet continues, the CLI really needs support from a "neutral motherload language" like C++. This would allow CLI to gain some clout and really move to the next level. This is the reason Ecma is tying C++ to CLI.
Times like this I long for BASIC ... okay not really. Logo maybe ;-).
February 20, 2006
C# vs VB.NET... is there a difference?
Coding horror compares Coke vs Pepsi as an analogy to C# vs VB.NET. The post is an interesting one for me, not because I'm a programmer, but as a product manager. I have to ask myself when choosing a coding language ... which is most compatible, which has the best support and documentation, which is the easiest for that programmer to code in, how easy is it to find other people to program in it?
Technical considerations aside, sometimes the real-world considerations are the ones that make the final call.
February 15, 2006
Scrum plugin for Visual Studio
February 06, 2006
.Net and QA are the hot jobs right now ...
From CNN Money:
Two tech jobs in high demand these days are .NET developers and quality assurance analysts.
Developers who are expert users of Microsoft's software programming language .NET can make between $75,000 and $85,000 a year in major cities. (See correction.) If they pursue a job at a company that seeks someone with a background in a given field (say, a firm looking for a .NET developer experienced in using software related to derivatives) they might snag a salary hike of 15 percent or more when they switch jobs.
Those who work in software quality management, meanwhile, might make $65,000 to $75,000 a year and be able to negotiate a 10 percent to 15 percent jump in pay if they switch jobs.
Break out the resumes ... if you are a .NET whiz or a QA master (dare I think about if you're both!) according to CNN Money they are the two hottest areas in tech right now.
But ... from my experience as a manager during the DotCom boom ... jumping ship just to get more cash isn't always the best course. One of my best programmers jumped ship to a little start up and wound up working in an environment where they hired 12 people for about 6 slots ... you had to program great stuff to keep your job, and you knew people where going to be let go. So ... caution is always the best course in times like these.
January 28, 2006
Don't hide these buttons ... save yourself some time ...
I came across this tip on SecretGeek. A couple buttons in Visual Studio .Net that make your life easier in programming. The first is View Code, the other is View Designer. It seems that Microsoft hid these buttons from view in Visual Studio. So ... take two seconds and customize your toolbar.