Darrell Norton, in this post, recently blogged on the limitations of object-oriented solutions. I think Darrell has overlooked the benefits of a very prevalent pattern in use since the dawn of software development.
SCOP, pronounced “ess-cop“, has several benefits:
- Developers will achieve code completion in half the time.
- Zero chance of over architecting the application.
- Beginners can implement this pattern immediately. No spin-up time required.
- All coding is directed at adding new features that the customer can see. No development effort is wasted on “behind the scenes” code.
- Unit testing is a simple process. Simply press F5 (the little green play triangle) or whatever button your Debug command is associated with. Who needs TDD anyways?
- Encourages “heads down” programming. Some may even fall asleep!
- No need for needlessly long requirements gathering sessions where the churn never ends.
Yes, you and your development team can achieve these results by simply implementing the principles of SCOP (Spaghetti Code Oriented Programming).
--Mark
Today I was looking for a tree view control for sub navigation in an image gallery.
Situation:
Budget for controls: $0
Time to develop a custom control: 0
Time to test expensive third party controls: 0
Finding the perfect control in under 30 minutes: priceless.
I believe it is good to give credit when credit is due, especially since most people will only comment when they have something negative to say.
I did a Google search for free tree view controls. I eventually made it here: http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=a096c052-520e-4fdd-9e64-9ff0875e59a6
This control, squishyTREE, was developed by Adam Sills. This control meets my needs 100 percent! Full source code with nine samples are provided. squishyTREE is very easy to use. It can be wired up to a DataSet, XML file, etc. I had no problem hooking up my existing CssClass. If you need a tree view control, check this one out FIRST. It is far better than many tree view controls that I would be willing to pay for.
Great job Adam!
Paschal asks What about other .NET languages? I have my own thoughts on C# and VB.NET. But to extend his question, I would ask is having them a good thing in the first place?
Scenario:
Suppose a company, perhaps a government department or a government contractor has a staff of COBOL developers supporting the mainframe (I know of some that still do), but the *young* blood has a .NET initiative (they have seen the light) that needs to be manned with no funding available for outside consultants, new employees, etc.
By using COBOL.NET for a piece of the application, you can leverage the talents of the more *seasoned* developers and lessen the learning curve.
Yes there is still OOP to consider and you cannot just say “well I know COBOL so I should automatically be productive in COBOL.NET and therefore the .NET platform.” This is not the case when transitioning from VB to VB.NET, and it’s not the case when transitioning to .NET through other languages either.
Making the transition to the .NET platform via C# was easier for me than VB.NET. I had to change my approach to the way I write code. You cannot just map old language habits to .NET. This assumption is partly the cause for .NET getting a bad name. Low quality consultants are being marketed as .NET experts after only three months of experience; I saw this happening firsthand. When the application does not perform to expectations because of poorly written code, .NET gets the blame (a blog for another time).
There are a lot of *antique* developers out there that think .NET is just a new syntax for their favorite language. Switching to .NET is a paradigm shift. It’s a new way of developing. Some say Java has had this type of framework for years, and .NET cannot hold a candle to J2EE. I'll let the Petstore benchmark fight that fight.
The above company can now begin to focus on an organization wide framework to build upon. This framework can be utilized by all the departments, unifying the company infrastructure. This will allow the *antiques*, the *young* blood, and everyone in between to get on board with a unified development environment. This would increase code reuse between departments which is normally difficult to accomplish, and it would decrease development time of future initiatives regardless of the language used. Its all about the runtime.
So having these other languages under the .NET umbrella is a good thing.
This may be a maintenance nightmare later on, but for the above scenario, it is acceptable.
This page has been moved to CodeBetter.Com. Please update your links accordingly. The new post URL is: http://codebetter.com/blogs/mark.digiovanni/archive/2003/12/03/4199.aspx