Try something different

By mOrPhie on Thursday 30 September 2010 10:45 - Comments (10)
Categories: software engineering, techrelated, Views: 8.210

Sometimes a software developer makes a fundamental decision without even realizing it. A C# developer almost always chooses MS SQL Server as the preferred database. What does that decision imply? The data is stored in a relational manner. The data isn’t easily transferable. The model is fixed. You need a license. To install the software, you need to install a SQL Server. The database must be maintained in some sort of way, ect... The implications of such a decision are so big; only an architect should make that decision, shouldn’t he? And he should be very explicit about it.

The reality is that in most C# projects the choice of RDBMS isn’t a logical decision, but based on what the team is used to. That concerns me. Think about it. What if SQLite would fit my needs just perfectly? That would save me the time of installing the server, I am able to copy the database as a file and it is free. I’m not saying you should use SQLite in all of your projects. I am saying you should consider alternatives and ask yourself why you should use it and what part of your software problem it fixes. Maybe XML could fit your needs. Maybe you don’t need a relational database and a document-based database like MongoDB is something to consider.

I’m sure you can imagine this can be applied to more than just databases. The language, the framework, the runtime, the tooling, the software architecture… Surprise yourself and maybe, just maybe you’ll find yourself doing an IronPython project with Django, the .NET DLR, persisting your data in MongoDB. Although I highly doubt that you’ll come up with that combination through a logical decision process ;), it helps you think about the “way to go”.

Subconscious prototyping

By mOrPhie on Tuesday 21 September 2010 18:30 - Comments (3)
Categories: software engineering, techrelated, Views: 2.771

If your software development is slow and painful and productivity drops every day, consider this: Are you fixing the problems caused by development that was actually prototyping because you didn’t understand the problem you needed to solve just yet? If this is the case: start over and use your new found knowledge to create a better base and dodge the productivity problems you faced earlier.

What happens here is what I call “subconscious prototyping”. If you are faced with a project in which specs are vague and development is somewhat unstructured, you might find yourself developing software, while solving a problem at the same time. Those who are able of doing just that without problems are a very rare breed. Or, of course, the problem to solve is a very simple one.

Even better is to understand the problem and its solution before you start typing away. So, the lessons learned: 1) Nominate problems and concepts that are hard to understand for prototyping, detailed design and design reviews. 2) If you still get stuck, notice “subconscious prototyping” as soon as possible and consider re-planning before it’s too late.

This might sound obvious to you, but some projects need this reminder every now and then.

The Software Quality Poem

By mOrPhie on Tuesday 14 September 2010 22:49 - Comments (10)
Categories: business, software engineering, techrelated, Views: 5.083

Bugs, faults, errors and defects
They are all the same to me
Please ignore the name
Value the severity

Feature popularity
Specification compliancy
And customer satisfactory
All define the priority

Unit testing, code review
Architecture and design
Prevent a list of bugs to grow
And make the software shine

So, if you find yourself
Fixing a bug or three
Think of this poem before moving on
And improve software quality