Where Scrum Falls Short and Software Engineering Has to Pick Up

For any company that adopts Scrum, there will be an initial period where productivity dips a bit while everyone understands the process, but then within a very short time their productivity will spike higher. Ayende Rahien in a recent post gets into a some excellent detail into where Scrum as a “Product” development process falls short when developing software.

The reasons for this are pretty obvious when you look at Scrum side-by-side with what we know to be best practices for software engineering. It isn’t until you understand what each bring to the table that you can see their shortcomings and then blend the two together to create a process that brings the strengths of both together to bear on the problem.

Scrum’s short iterations, frequent feedback, and quick turn-around are clear winners. It shortens the feedback cycle and makes staying focused on the highest priorities for the Product Owner much easier. It also allows for changing direction when requirements change. However, as Ayende points out, there is nothing in this that is software-specific. That’s where software engineering practices like Test Driven Development, Continuous Integration, and Refactoring come into play. These work together to ensure that the “product” is built using best practices that focus on the actual product and the idiosyncrasies of its development.

It is critical that these best practices be interwoven into your software development process – especially an Agile process like Scrum. Because without them, you are missing out on the aspects that emphasize quality. Over time, as quality declines, so too will your velocity. Ayende describes this:

“You hit the Scrum wall when you adopt Scrum and everything goes well, then, after a few Sprints things don’t work any more - to use an English expression, they go pear shaped. You can’t keep your commitments, you can’t release software, your customers get annoyed and angry, it looks like Scrum is broken.”

How many times have you gotten a few sprints into your project, and then had to put on the brakes to introduce a “go back and fix stuff” sprint? For our team, it happened a lot early on before we adopted those best practices. After adopting them, we rarely had to go back to code due to quality issues; rather, we were more likely to have to revisit code due to changes in requirements or additional features being added. Clearly this is much better – we’re now focusing on business drivers and less on technical debt.

Bottom line – don’t forget to roll into your process the details for following the software engineering best practices. Let Scrum manage what it does well – requirements and deliverables. When you include the best of each of these your product will benefit greatly.

del.icio.us Tags: Agile,Scrum,TDD,ContinuousIntegration,Refactor

Exporting Table Definitions from SQL Compact Edition Database Files

While working on a mobile app that uses SQLCE, I was unpleasantly surprised to find that there was no built-in capability for the SQL Server 2008 Management Studio to export table definitions into a script file. So when I found that @ErikEJ on the CodePlex site had written this little plug-in I was quite happy.

Thanks Erik For a very useful little utility :)

del.icio.us Tags: sqlce,codeplex,programming

Writing Stored Procedures for SQL Server 2008 in C#

This is my first foray into writing stored procedures for SQL Server in managed code. I decided to check it out since I was already doing some other SQL Server work in support of a WPF-based Agile project management application and thought this would be a good opportunity to explore a little and see how it might apply.

Let me be clear, this is a post really to capture my thoughts and experience along the way. I’ll include links and quotes where it seems applicable.

Decision Points

From “Overview of CLR Integration” - http://msdn.microsoft.com/en-us/library/ms131045.aspx

Choosing Between Transact-SQL and Managed Code

When writing stored procedures, triggers, and user-defined functions, one decision you must make is whether to use traditional Transact-SQL, or a .NET Framework language such as Visual Basic .NET or Visual C#. Use Transact-SQL when the code will mostly perform data access with little or no procedural logic. Use managed code for CPU-intensive functions and procedures that feature complex logic, or when you want to make use of the BCL of the .NET Framework.

Choosing Between Execution in the Server and Execution in the Client

Another factor in your decision about whether to use Transact-SQL or managed code is where you would like your code to reside, the server computer or the client computer. Both Transact-SQL and managed code can be run on the server. This places code and data close together, and allows you to take advantage of the processing power of the server. On the other hand, you may wish to avoid placing processor intensive tasks on your database server. Most client computers today are very powerful, and you may wish to take advantage of this processing power by placing as much code as possible on the client. Managed code can run on a client computer, while Transact-SQL cannot.

* Note: I have some reservations about the suggestions made in the last section. While many business-class PCs today have more processing power, and while scenarios may exist where it would be nice to distribute the computational work to the client, it is likely unreasonable to place the burden of processing on the client PC due to the need to transfer the required data to the client. This seems like a corner case, which probably doesn’t happen often.

Advantages

While reading through the various articles, I came across this list of advantages for using managed code instead of Transact-SQL.

• Enhanced programming model
• Enhanced Safety and Security
• User-Defined Types and Aggregates
• Common Development Environment
• Better Performance (for computational sorts of logic; see the point above regarding straight data access)
• Language richness
• Reusability of code
• Extensibility
• Leverage existing skills
• Richer development experience
• Stability and reliability

Step-by-Step

1) Create the database project in your solution. Click the database category and choose the “SQL Server Project”. Give it a name and choose the directory where you want it created.

The wizard will create a .SQL script from which you can test the database objects that you create.

2) I decided to create a subfolder in which I’ll place my new stored procedures

3) After that, right-click the new folder and add a new stored procedure; give it a descriptive name. Use a naming convention that lets you know what the stored procedure does. I prefer to prefix my stored procedures with the name of the module of the app that it applies to; e.g., Products_InsertNewProduct or Products_SelectProductById

4) The stored procedure template will give you a basic outline for a stored procedure. The first thing you’ll notice is that it creates a static method on a partial class. Also, the method is marked up with the Microsoft.SqlServer.Server.SqlProcedure attribute.

5) Modify the signature of the method to include the parameters that you want

6) The implementation of this is pretty much plain vanilla ADO.NET; There are a couple of minor differences to make note of:

a. The connection string for the SqlConnection is based on the current context that the stored procedure is running under:
”context connection = true”

b. When returning data, you use the SqlPipe, which is accessible from the SqlContext

7) Next, compile and deploy the project. Both of these commands are available from the “Build” menu.

That’s about it for now. You can use the Test.Sql script that is generated in the project in order to test your procedures. Going forward, I see lots of potential for code reuse. My next post on managed code for SQL Server will focus on triggers and user defined types.

Have fun!

Related Links

Introduction to SQL Server CLR Integration (ADO.NET)

Overview of CLR Integration

Creating SQL Server Objects in Managed Code

del.icio.us Tags: sqlserver,c#,code,programming