Welcome to AspAdvice Sign in | Join | Help

Regionerate - blogged by Roy Osherove

Roy's blog is a goldmine for great advide and tools ... this morning he posted Regionerate - Free Code Layout Addin for VS.NET - ISerializable - Roy Osherove's Blog

Regionerate looks like quite a cool little tool, maintaining 'stuff' in the right place is always a fun task, and this has the makings of a good starting point. I'm not sure if it can really do things to the extent I might like yet, but there is plenty of scope for the future!

Superb work Omer!!!



Technorati Tags: , ,
Posted by Insane | (Comments Off)
Filed under: , ,

Peanut, Peanuts, Get Yer Peanuts Here! This One Will Go On And On

Nick's thoughtful reply to my post, yet again deserves it's own post.

I have seen many magic quadrants, however they all tend to suffer the same limitation, they attempt to squeeze infinitely variable properties into a limited set of constraints or qualities.

I do appreciate that many of your comments of explanation were an attempt to explain away this ambiguity, but it still exists, I don't think Mort fits into any of those boxes (infinite axis / compressed attributes or not), as I don't think Mort follows any of the good coding practices built up over decades of development.

You also took only two of the Agile manifesto principles, ignoring the other two, which probably also excludes Mort from being Agile. In addition, Agile places more value on the items on the left, but it doesn't exclude them - for example you can be fully Agile, and yet provide totally comprehensive documentation.

Nick said:

I tried to make the case that the attribute that most greatly differentiates Mort from agilists, code maintainability, can be factored out of the equation if we constrain Mort to a "little or no code" or "disposable code" environment.

The qualification that Nick is excluding code maintainability within his criteria is a little bizzare, because in my opinion, maintainability is one of the most fundamental of good development practices.

We can constrain Mort to the "no code" environment, but does he know what happens under the covers when he calls a service? Does he know how many data access requests that might make? Does he know how to properly secure his requests? Sadly not.

We can also constrain him to the "disposable code" environment, and from a cost issue point of view, many organisations will hire Morts for precisely that reason, their business case doesn't justify doing it properly. But those organisations will almost certainly end up paying more in the long run, if not paying exactly the same in the short run in addition.

As I don't see Mort following any good development practices, he either isn't a professional developer (in any traditional sense), or development is heading down a very rocky road.

I believe there is a very good reason why it is exceptionally hard to produce high quality software via outsourcing, or via hiring a lot of Morts and a couple of Einsteins.

Development is not a technical craft. Development is part technical, part creative and part psychology.

You can mass train all the developers you like, and teach them all the technical aspects of .NET, C# or whatever other platform is flavour of the day, but you will have a hard time teaching them the psychology part, and creativity is impossible to teach. Nick is proposing that now they don't even need to know the technical aspect, just how to drag and drop. 

So we are now heading towards the infinite monkey scenario.

As I conceded to Nick fairly early on in the debate, Nick may well be right that Mort is the future - I just don't want any of the aspects of my life depending on the software he is going to write!

Peanut, peanuts, get yer peanuts here!

Mort Still Isn't Agile!

The debate goes on ... but Mort still isn't Agile!

I appreciate Nick's clarifications, they have helped clear a few misunderstandings, and I'm sure Sam appreciates the apology :)

I think Nick's problem started with the boxes.

Nick puts working software over comprehensive documentation. But how do you define working software?

Nick seems to define it as 'something that appears to work right' ... in which case Mort can sit in the agile box, tapping away with his drag and drop interfaces.

The only problem with Nick's definition is, Mort can't prove it he has working software.

Firstly, Mort is dependent on his services. He gets his services written by 'clever people' - and the clever people tell him the services work right. But he really has no evidence to that effect, and as he doesn't know about testing, he can't be sure.

Secondly, his own code has snippets here and there, and he can't even prove to his boss that his code works. As long as he is only linking services a la Popfly, then he may get away with it. But if he starts using MS Access to provide a stock control system, with a few dozen macros and some VBA, and a couple of .NET addins he downloaded off the Internet, it's anyone's guess what will happen.

To me, working software is not the appearance of working, but the proof of working (as far as possible).

So fundamentally, using Nick's boxes... I don't put Mort in the Agile box.

He didn't produce documentation either - so actually he can't really be placed according to that axis.

Can Mort even be aligned on the vertical axis? He uses tools for everything - his job is just using other people's tools. He may not have any processes though. He certainly values people and interactions, he believes he is working in the interests of his users, and his people skills will come in handy on his job applications.

I don't think Nick's box contains Mort at all - because all of the boxes have at least some well defined standards of good practice, levels of documentation, levels of testability or evidence of testing scenarios. And Mort doesn't really want to be bothered by all of that - he just wants to get on and code something. He is the archetypical hacker.


I just want to get on and code something too. No, I *really* do. Sometimes however I'm smart enough to stop, think about things, draw some things out on paper or a whiteboard, discuss options with colleagues, spike a few unknowns, and all that other boring stuff that Mort doesn't concern himself with.


I think Mort has his own box. It has REST services on one side, it has VS wizards on another side, it has VBA on another side, and on the last side it has a blender. Mort's job is to pull all of those things together into the middle, power up the blender, and start preparing his CV for his next contract when he is unable to bluff his current employer any further that he knows what he is doing.

Mort is Bad! Mmmmmmkay!

Posted by Insane | 9 Comments

When All You Have is a Hammer, Everything Looks Like a Nail!

It started with a controversial post by Nick, my own blog on the subject seemed to awaken him.

Nick kindly commented on my post, and as his comment deserved a longer reply ... here it is ... (the quotes are all from Nick)...

I find that I'm being misunderstood a lot lately.

Sorry :)

Would you agree that Mashup developers are building systems on services?  Would you agree that in that situation, we have developed an ARCHITECTURE that is fundamentally agile?

Sure they are building systems by *using* services. You have developed an architecture that exposes services, but that isn't agile. Not even with a little 'a' is that agile.

Would you find a mashup developer to be "not agile" just because he is writing small amounts of code and demonstrating value quickly?

He may be agile with a little 'a' - but he is just (at heart) a hacker. He isn't a professional developer on that basis, as he isn't thinking of the bigger picture. He isn't thinking about maintenance, future developments, scalability, and every other annoying detail that real developers need to be aware of.

Professional Agile developers follow FORMAL methodologies - just ones that embrace change. Just because you embrace change does not make you an Agile developer.

Mashup and Web 2.0 are the outcome of following the lines of thought developed originally in the agile manifesto.  Just as JUnit arose out of "following the principles," so did REST-based service design.  

Web 2.0 is a bit of a marketing slogan - I agree that things like SIlverlight are superb in what they allow you to do, but fundamentally they are also capable of being abused and creating nightmare maintenance scenarios. Where is the source control for all those little snippets of code, where is the testability (unit or otherwise)?

One tool is not better than another.

Indeed ... some tools are considerably better than others. If you mean Silverlight isn't better than DHTML (or vice versa), then for a particular scenario and application, yes it is - and vice versa.

No, I'm not saying agile = cowboy or agile = hacker.  However, I am saying that you should write only the code you need to write to get the job done, and very little more.  That's a fundamental of TDD.  

Mort believes in that, even though he doesn't know TDD or JUnit.  

This is the line that had me reacting... Mort doesn't know some fundamental basics of development. He may choose not to use TDD if he knew what it was, but as he doesn't, he just hacks it together in Access and Excel ...

Mort is dangerous!

Mort is why I spend half my development time looking at Access databases that some half witted genius who claimed to have once done computer science has hacked together to solve his department's current problems. And it never does. It just creates a need to do it properly, but now doing it properly takes 3 times as long as having no half wit in the first place.

It's the values that count.  The rest is tools.

It is knowledge and experience that count. The rest is irrelevant.

When you only have a hammer, everything looks like a nail!

Posted by Insane | 2 Comments

Morts = Cowboy Coders?

Nick's definition of Mort's and their practices seems to me a lot like 'Cowboy Coders' or 'Hackers'

Maybe I'm reading him wrongly, but he just seemed to claim that the drag and droppers are the future (in which he may well be right) but more oddly that they are AGILE !!!!!!

Agile ??? Hacking ??? Drag and Dropping ??? Mashup artistes ???

Agile methodologies are FORMAL METHODOLOGIES - they have practices, structure, accountability, maintainability.

Nick's definition seems to throw all that out the window and claim just because they go balls to the wall, they must be the foremost Agile proponents.


Posted by Insane | 2 Comments

Documentation Can Be Ambiguous in the Most Insidious Ways

Ayende started with a bold statement ... 

Frans has a long post about how important is documentation for the maintainability of a project. I disagree.

You can read all of it at  Working software over comprehensive documentation, but for me the whole thing was summed up beautifully with a single sentence deep in Ayende's post:

Documentation can be ambiguous in the most insidious ways

Never has a truer word been spoken!

Posted by Insane | 1 Comments

In Response To Rob

Now I rarely bite... but Rob deserves a reply (and plus, until my 9pm meeting I have little else to do! :)

Rob said (in response to my comment on his blog):

@Casey: Come on homey - gimme a little something here. Your comment is just ridiculous - unit test - well I'll give ya that but strong typing - what does that mean when talking about SPs? I shoved the results into a collection - what more do you want?
Intellisense? Can I get you a beer with that? You're making us look like dopes Casey... there's a world out there without intellisense...
"Proper language constructs" - if you don't like SQL I can't help ya.
"... didn't often result in execsql..." so SPs jump out of your DB and rewrite themselves?
Normally I would let this comment go but I like you Casey - this comment has me baffled though. Perhaps you want to try again?

Well the things I brought up were :


I don't know if it makes *your* life easier, but is sure as hell saves me a lot of work, in fact SQLPrompt is a godsend of a tool, but more oddly, one of the things that is best about SubSonic (and is in the example videos/tutorials) as a strong selling point, is Intellisense. Can you exist without it? Sure, but it really sucks.

Funnily Rob, it would have been easier to catch me on 'well sure Intellisense is nice, but HQL doesn't have it'  :)

Strong Typing

Again easier to get me on 'HQL doesn't have it' - but sure I like strong typing... I don't like having result sets inside a SP, that other parts of the SP may then manipulate, and the old 'execsql' get out that often appears to make it worse.

Having SPs return recordsets that I then have to wrap in a DTO, or inside (even worse) a DataSet, or worse still the dreaded Strongly Typed DataSet ... errrrghhhh!

Unit Testing

Well that point you accepted, but you still could have got me there by saying 'well I can wrap my SP inside a Unit Test too'. But when your unit tests start failing because your DBAs own the database, and they can't write unit tests ... who ya gonna call? Ghostbusters?

Proper Language Constructs

Nope, I don't like SQL much, it sucks. It is a black art. It should be left to DBAs or database developers who do nothing more than code SQL (I am a firm believer that people who code in Java, C#, C++ or any other similar language should be nowhere near SQL)


So ... I'm having a really hard time with my T-SQL ... the language constructs suck ... I want to make a Search procedure that takes 5 parameters (for example the fields on an employee record), and then produces a search for all employees that match those search parameters (what happens if the string is empty? are the fields to ANDed or ORed, etc) ... the T-SQL is becoming a monolithic nightmare ...

Solution? String concatenate within the SP (because your company policy is that all data access must be via SPs) ... create a SQL string that matches your queries, and use execsql.

Sounds ludicrous right? I must have worked at half a dozen places where this, and much worse, was done as a matter of routine.


And honestly - above all that - you have created another API ... and when an API becomes published (as opposed to public) - it essentially becomes immutable and fixed (COM has a legacy of IMyInterface2 for just this reason)

You create all your SPs - and you start to use them, and then when somebody wants to add a new field onto your employee class ... everything breaks. Sure it would do too (to a lesser degree) in an ORM, but at least it would be under your control.


I have been at multiple companies where the database has become the application (the Oracle world view, but on SQL Server), and the app servers and web servers have been relegated to UI and data transfer duty. That may not be so bad - except almost always the database has become the legacy application that you are struggling to maintain, with the assistance of less than helpful DBAs who are mostly interested in maintaining their database structure over your application needs.

There are *many* good arguments in favour of SPs, but maintainability shouldn't be in your list.

Should Ayende Rise To Rob's Challenge?

Ayende asks how he should write the code to demonstrate the ORM solution to Rob's question ... Well - if he feels the need  - then I suggest Web Forms or Monorail ...

But is there a need? Any example problem has multitudes of possible answers, and any given answer has multitudes of ways to critique it.

I honestly don't think there is much of a debate, other than that based on individual's experiences.

Case in point, I Interviewed a guy yesterday, and one of my standard stock questions is:

"can you name some of the differences between stored procedures and using dynamic SQL, and the reasons why you should choose one over another?"

He gave a number of the stock answers, many of which are wrong or myths (stored procedures are much faster as they are pre-compiled, stored procedures are more secure, stored procedures can't suffer SQL injection attacks, etc)

However, it turned out when I probed deeper, not only hadn't he really used dynamic SQL in any form, but he didn't know what ORM stood for, had never heard of Hibernate (or NHibernate), and didn't understand that the Java/Oracle view of the world is very different to the MS/SQL Server view of the world regarding recordsets vs cursors, stored procedures vs ORMs, etc ...

So ... it all comes down to your world view. You can't really win by taking a given example and proving your way would solve it better, because as we all know, development is a , and until you have a finished solution, you are just making best educated guess as to the best way to solve it.

Posted by Insane | 1 Comments

Hope to Desperation!

The weekend started well, I have the authorisation I need to hire 4 top notch developers, I send out a short interview test to the agencies, and am told they have some good people.

The test is simple ... to write a small application that can tell the difference in days between 2 dates. There are only 5 basic requirements:

· It should be written in C# and .NET

· The code must not use the DateTime or other date functionality provided within the .NET library, this is a test of coding, not of knowledge of the .NET FCL

· The code can be as complex or as simple as you think is needed to meet the requirements.

· The code must be able to be compiled, run and tested.

· The code should be supplied in a Zip file

There is also a set of test data.

Should be simple ... or so you would think...

So far, terrible code has been sent to me. One example (apart from being untestable due to being a single method in an aspx page) made at least 5 or 6 fundamental programming mistakes including catching Exception, using x=x+1; rather than x++; , and ignoring my requirements entirely by using DateTime and TimeSpan ...


So ... I'm back to despair...


Windows Live Writer

Well, I finally got bored of using a web interface to blog, and downloaded Windows Live Writer ... What a breath of fresh air!!!



The Pragmatic Data Access Discussion

SubSonic is a great product, and while reading up on it I came across a superb post on data access in general.

I think Rob let the whole ASP.NET drag and drop data access get off lightly ... but oh well :)

Posted by Insane | 1 Comments
Filed under: , , ,

Ruby or Not Ruby ... and some ORM/Relational Database vs Object Database Stuff

Scott Hanselman started yet another great debate ... on Ruby and why it is the '***'  ...

Today I came across a great artice (via Frans Bouma), called In Defence of the RDBMS - a very well written debunk of a number or database theorist's views.

 The two get mentioned together as I loved the comment half way through the RDBMS article that said:

It might be nice if the whole world used Java, but they don't. And Java won't last forever. Really it won't. Heh, that's fine by me, just as long as it's not Ruby that replaces it (I feel safe to say stuff like this, since I am guarded around the clock by an elite team of five hundred crack female IDF commando ninjas armed with the big machine guns out of Alien II).

This made me chuckle... but the comment at the end made me laugh out loud:

P.S. This was something I wrote a while ago, but never posted because I felt it was too intemperate. The Ruby cracks are a bit dated now that the Rails hype has faded and most people are getting back to doing real work.

And that for me sort of sums up Ruby ... great lanuguage, and no wonder the Alpha Geeks love it ... but I have to do work today ... and for that Ruby isn't the answer (today)



More Posts Next page »