Fwd: Target vs General and .NET shops

[Sean Copenhaver]

Speaking of discussion threads.

---------- Forwarded message ----------
From: Sean Copenhaver <sean.co...@gmail.com>
Date: Fri, Aug 12, 2011 at 7:12 AM
Subject: Re: Target vs General and .NET shops
To: Bryan Matthews <matt...@gmail.com>
Cc: "David P. Donahue" <cybe...@gmail.com>, Chance Dinkins <chan...@gmail.com>

I always feel like Hanselman is a MS Douche based on his picture, but the interview was great. Some great questions and the interviewee hit some great points about what different languages could buy you. Also that .NET's CLR and DLR were created so multiple languages could interoperate nicely. 

Something I remember from the interview is that Towlson mentioned about how in the beginning of .NET there was only VB.NET and C#. He feels that many developers started to think that languages are just syntax. I have run into this a couple of times before. 

-- 
Sean Copenhaver

Sent with Sparrow

On Thursday, August 11, 2011 at 7:58 PM, Bryan Matthews wrote:

I thought you guys might find this interesting.  I was curious about the implementation when I heard about web workbench.  I was hoping they didn't try to re-implement these tools, and it turns out they didn't, they used the originals for the most part with a combination of iron-ruby and Jurassic.  Also interesting to hear the guy explaining why they used F# to a crowd that is probably coming from the perspective of "why not C#?".

http://www.hanselminutes.com/default.aspx?showID=297

On Wed, Aug 3, 2011 at 8:01 PM, Sean Copenhaver <sean.co...@gmail.com> wrote:

Hmm.. I don't think I replied to all last time.

-- 
Sean Copenhaver

Sent with Sparrow

On Wednesday, August 3, 2011 at 8:00 PM, Sean Copenhaver wrote:

That's a great response that provides the perspective from a completely different side of things. One that is both from a more business perspective but also from a consultancy one. Which neither were considered in my original e-mail.

In my Erlang vs .NET example, what raises my eyebrow is that if the problem was truly a good fit for Erlang but you wrote it in .NET anyway, then sure it'll be easy to find someone who could write C# (there's tons of people who can write it). It'll be hard to find someone qualified to work with the code. If you understand my meaning. Your costs and down time may go up considerably and for longer but it's nearly impossible to put a number on unless you stumbled through both and measure them. Simply because the solution will be more complicated and harder to maintain.

You could probably make a similar argument with having a solid testing practice versus not. One certainly costs you more time because you are writing twice as much code, but you can only perceive the short term unless you have trends and experience with both long term. Generally I think we all agree that a solid testing practices leads to long term sustainable productivity and success.

As for the "nobody got fired for choosing Microsoft", people used to say the same thing about IBM but that expression seems to have changed in the enterprise world. So my point here is that it doesn't matter, if you are relying on a single closed source vendor you are putting yourself in a considerably tight spot. One that only benefits the vendor.

So back to this consultancy thing. It certainly seems like we both recognize the deficiencies if you are a company that depends on it's own technology/platform. In your current company, you completely depend on what your customers use, because they are asking for your to implement and hand over projects that fit into their IT department. One that is obviously not geared up for the task. I totally get that. 

Hell if enough places around town wanted Ruby or node.js then you guys would probably consider that. But for a company whose customers just want the service to be better it's a different story. Nobody cares what your product and infrastructure is implemented in except for the people working on it. 

Great stuff. 

 
-- 
Sean Copenhaver

Sent with Sparrow

On Wednesday, August 3, 2011 at 7:58 PM, Sean Copenhaver wrote:

That's a great response that provides the perspective from a completely different side of things. One that is both from a more business perspective but also from a consultancy one. Which neither were considered in my original e-mail.

In my Erlang vs .NET example, what raises my eyebrow is that if the problem was truly a good fit for Erlang but you wrote it in .NET anyway, then sure it'll be easy to find someone who could write C# (there's tons of people who can write it). It'll be hard to find someone qualified to work with the code. If you understand my meaning. Your costs and down time may go up considerably and for longer but it's nearly impossible to put a number on unless you stumbled through both and measure them. Simply because the solution will be more complicated and harder to maintain.

You could probably make a similar argument with having a solid testing practice versus not. One certainly costs you more time because you are writing twice as much code, but you can only perceive the short term unless you have trends and experience with both long term. Generally I think we all agree that a solid testing practices leads to long term sustainable productivity and success.

As for the "nobody got fired for choosing Microsoft", people used to say the same thing about IBM but that expression seems to have changed in the enterprise world. So my point here is that it doesn't matter, if you are relying on a single closed source vendor you are putting yourself in a considerably tight spot. One that only benefits the vendor.

So back to this consultancy thing. It certainly seems like we both recognize the deficiencies if you are a company that depends on it's own technology/platform. In your current company, you completely depend on what your customers use, because they are asking for your to implement and hand over projects that fit into their IT department. One that is obviously not geared up for the task. I totally get that. 

Hell if enough places around town wanted Ruby or node.js then you guys would probably consider that. But for a company whose customers just want the service to be better it's a different story. Nobody cares what your product and infrastructure is implemented in except for the people working on it. 

Great stuff.

-- 
Sean Copenhaver

Sent with Sparrow

On Wednesday, August 3, 2011 at 7:28 PM, David P. Donahue wrote:

After transitioning from the closed enterprise environment (where everything is internal) to an open consulting environment (where everything is a contracted deliverable to a client), my views on this have seen some interesting changes.

I guess I should preface by saying that my employer has always been "all Microsoft all the time" and I have always been, well, the complete polar opposite of that.  Recent trends (which indeed began over a year before I started at this company) seem to indicate that we're going to meet somewhere in the middle.  But in the context of this discussion and this audience, I'm probably just going to sound like I'm playing devil's advocate.

A lot of times a business will treat even their internal IT as an external consultancy.  On paper it all looks very much the same.  No money comes out of IT.  For a company whose business model isn't IT, it's a black hole of expenses with no tangible results.  Indeed, one of the greatest challenges of our industry isn't building great software but is selling the idea of building great software to our business overlords.  So the business wants numbers they can use.  They want to comfortably say things like, "This application cost us X dollars to build and saves us Y dollars per month in operational costs, and therefore will need to be used for Z years until we break even."  So when anyone, internal or consultant, comes in and says, "This needs to be replaced," the words fall on very deaf ears.

To that end, they want to be able to predict that the software will still be usable and supportable for Z years.  If you ask any business man in the world what software vendor is going to still be strong Z years from now, the answer is very often Microsoft.  It could just as easily be Java, Oracle, etc. depending on the context.  But the pattern is the same.  The answer is the _easy_ answer.  There's a lot of truth in the saying "Nobody ever got fired for recommending Microsoft."

In terms of making the "safe" recommendation, consider also the paradox of management… A person is promoted because they do their job well, until eventually they reach a point where they are no longer promoted.  Which means they eventually reach a point where they no longer do their job quite so well.  Playing it safe keeps them there.

If a manager/director/executive/etc. makes the decision to go a more "radical" route, they're taking a risk.  The Microsoft route may be less efficient, but it's a predictable lack of efficiency.  It's known.  When given the choice between "this will cost $10,000" and "this will probably cost $6,000, but we can't say that for certain" the choice is often clear.  Planning for the known, even if it's more expensive, is easier than planning for the unknown.  Money does, in fact, grow on trees.  As long as you can give a concrete number, that number can be managed.

In trying to determine that number, for lack of a crystal ball that can see Z years into the future, there are a lot of things to be considered.  How many developers stay in one job for a very long time?  Sometimes a really good developer really clicks with a job he really likes and it's a match made in heaven.  But often… not so much.  So let's _assume_ that the developer who creates that Erlang software doesn't stick around for Z years.  How easy will it be to find another qualified Erlang developer?

The costs of managing the software are directly related to the often-unseen-by-developers costs of business operations.  Fixing a bug may cost $500 in developer time, but that time may have seen $5,000 in operational losses.  So while the business is looking for a qualified Erlang developer, they're hemorrhaging money in operational costs.  Sure, the possibly less qualified .NET developer working in the less efficient .NET code fixes the bug in $1,000 worth of developer time, resulting in $10,000 in operational losses.  But that number is perceived as being constant because .NET developers are easy to find.  Even in the absence of internal hiring, a consultant can be brought in very quickly and easily.  (Which will increase the developer time cost, but keep that operational cost right where it needs to be… in a predictable range.)

Now, it's my dream job to work in an environment where we have a whole internal team and we work together and learn together and share knowledge together, so that one Erlang developer who leaves results in nothing more than a project scheduling concern until a new developer is hired and can be brought into the fold and taught what he needs to know, which may in fact be Erlang itself.  But we're the only people who see it that way.  The planners look at us and see a .NET resource, a Java resource, etc.  If an Erlang resource is lost, an Erlang resource needs to be found as a replacement.  Not a strapping young lad who can be brought into the fold or a quality senior resource who can be brought up to speed.  An Erlang resource.  At a known and predictable cost.

At my current job, this all translates into what we can deliver to the clients as part of a contract.  If we have something that we know works, and we can demonstrate to the client that it works, and we can back it up with tons of industry expertise (read that as "industry money"), then we can sell it to the client.  Being experimental is cool for developers, but terrible for contracts.

As a case in point, take a look at my company's view on mobile development right now.  It's a very uneasy market for a company like this because demand is high and Microsoft support is pitifully low.  A few months ago we were swarming around the Mono development space and were ready to take on some projects to test the waters of that space.  But more recent events have caused us to question how responsible that really is to our clients.  As developers, it's a no-brainer.  But when a major firm contracts us big money to develop something that they can in turn own and support, can we in good conscience tell them that Miguel will find a way?

I guess my overall point is that in all of this rambling is that the immediate costs are heavily overshadowed by the future costs, the latter of which have many unpredictable variables.  Given those variables, in the often ridiculous world of business decision-making it usually ends up being a very reasonable and sane choice that a predictable cost is preferred over a lower cost.

--
Regards,
D²

Hofstadter's Law:
"It always takes longer than you expect, even when you take into account Hofstadter's Law."

On Aug 2, 2011, at 3:10 PM, Sean Copenhaver wrote:

Wanted to include the two of you to get your perspectives. Not really exclusive to .NET but it's really just me exploring my concerns with any more locked down monoculture type shop. This could be an Oracle/Java, a Microsoft/.NET, or some other. Although Java world seems to do more experiments with languages and technologies then .NET. At least that's my perception.

I used Erlang as sort of an obscure comparison. Many people would know nothing about it, but it was built from the ground up to solve a particularly hard problem, high availability concurrent systems. Were as .NET is not meant for that at all and we have to build up these service infrastructures and worry about threads, locking, message queues, etc.

In Bryan and my conversation we also brought up node.js. It seems like it could be perfect for certain internal service type scenarios and it would be much lighter weight then building a new Windows or ASP.NET service in C#. So perhaps that's another example but less obscure since a lot of developers can write JavaScript.

---------- Forwarded message ----------
From: Sean Copenhaver <sean.co...@gmail.com>
Date: Tue, Aug 2, 2011 at 1:33 PM
Subject: Target vs General and .NET shops
To: Bryan Matthews <matt...@gmail.com>


I wanted to keep our discussion going a bit longer.

So the question is simple, would writing something in a new but better fitting technology be cheaper in the long run then writing it in .NET? The issues are time to market, training, knowledge holding (as in keeping people around that know how to work on it), and long term maintainability.

Perhaps a nice example of the targeted vs general is databases. A relational database is not a good fit for a data model you work with in a heavily object oriented manner. So there is a lot of code that can be involved mapping it back and worth. Even with a solid ORM there is a lot of knowledge required to productively and safely work with something like NHibernate, mostly because it's large and the problem can be complex.

Would it be better to use a document database which more easily can store the object model but train everyone on the new technology and thinking in a document denormalized manner then a relational table normalized manner? I feel like the answer would be yes it'll pay off if you truly didn't need the relational databases features.

I feel like the same thing applies to Erlang and .NET. If your problem was focused around concurrency, .NET's model can become much harder to work with making it harder to maintain and reducing the number of potential developers anyway (how many would you trust working with threads and locking?). Where as Erlang, if truly a fit, would produce simpler software that is easier to maintain but require developers to learn it. We trust very new .NET developers with simple parts of our .NET applications, why not new Erlang developers with simpler parts of it.

I think a big problem is that if you never encourage your employees or give your employees time to work with and play with different technologies, then it is always .NET the safe and known city of light vs the scary unknown dark world. You put yourself in a position where any other choice could never look as good. But would a 5 month project that you'll be maintaining for multiple years offset any hard times you'll have in learning the platform and keeping someone around that can work on it. Of course if the project was a fit for Erlang then I would assume it would be easier to write, maintain, and understand once someone was trained with Erlang. Where as the .NET version would be harder to write, maintain, and understand even for a .NET developer.

Seems to me like every organization needs to provide some outlet for this exploration and consider options for any new project. A great example you gave was creating some kind of tool or utility. This should be encouraged and perhaps a certain amount of allotted time is understood. Next problem I see is that it's generally harder to get setup and running with just about all the things we discussed on Windows where as every other OS has a nearly standard package manager with huge repositories of developer tools. Must easier to tell someone to run a script or a command for a 'apt-get install <core package>' and be done with it. Hopefully NuGet helps solve this but it's primarily targeted at .NET OSS and provides (naturally) Visual Studio integration as a priority. Which of course brings up another issue I see, reliance on VS.NET.

Anyway, this should probably turn into a blogpost or something.

--
“The limits of language are the limits of one's world. “ -Ludwig von Wittgenstein

--
“The limits of language are the limits of one's world. “ -Ludwig von Wittgenstein

--
“The limits of language are the limits of one's world. “ -Ludwig von Wittgenstein

[Bobby Dimmick]

Wow you guys hit on a lot of topics in one thread.. There are a lot of great ideas and comments in here..  Some thoughts...

On Scott Hanselman:

Scott's a pretty nice guy.. I met him briefly at PDC '09..  He describes himself as a "technologist" with a true love of development tools and technologies.  He's fairly big on professional and personal development (read: image), so I can see how he can kind of come off as a jerk at first.

On Languages:

After coding long enough in a couple of dozen languages, you will find that for the most part moving between languages is more of a concern of syntax and semantics than technology.  If the '90's could be considered the decade for the rise of 4th Generation Languages, then I would classify the '00's as the decade of frameworks.  I think you'll find that the majority of the arguments over language X vs Y are really arguments over frameworks, utilities, and tools.

On How Companies View Developers:

Obviously, this varies from organization to organization.  I have done work for the state, work for private industries, and am currently a consultant.  I have been treated as a cog/FTE as well as a demigod.  A lot depends on the attitude of management.  One would think that the specific product or line of business on which the organization is based (i.e. producing a software package vs. SaaS vs. support development) would dictate the importance of individual developers, but that just is not the case.  Many developers (the smart ones at least ;) ) are very concerned with professional development, career continuity, and personal growth.  Unfortunately, most companies are only concerned with the bottom-line or billable percentages.  The smart companies out there realize that by enabling their developers (and IT staff in general) to grow (via training, working on pet projects, or doing R&D) they are building up another form of capital: knowledge.

On Choosing Technologies:

In every project on which I work, the two determining factors which define "success" are: the fundamental requirements, and the timeframe involved.  Customers generally could care less about technology.  In that sense, the tech becomes more of a marketing tool.  Do you think Facebook's 800 million users care about the underlying platform or tools used in development?  How about Twitter?  The small business owner using Quickbooks?  Turn that around and consider the project stakeholders, what do they care about?  Time to market/production?  Training?  Error tracking and ease of deployment?  Support?  What does the development team lead care about?  Efficient code?  Project velocity?  Near-seamless integration?  Developer familiarity?  I think if you took a cross-section of the above requirements, you might find what drives most technology decisions.

Can you think of a language/platform that does not deliver on the above requirements?  Given the right developers, enough time, and a decent plan, nearly any language or platform will work.

All of that having been said, and perhaps to address what seems to be the core question here - on what technology should I base my career, and how do I determine if that technology is the right fit for what I want to do - it depends: on luck, on careful planning, and on ability to take a risk.  I used to be a generalist.  If you dig up an old copy of my resume, you'll find 25 languages and 5 platforms listed.  At about the time that .net came out, I specialized in Java, ColdFusion, C++, and Visual Basic.  I did a lot of soul-searching over a weekend and realized that my career wasn't about the language or tools I was using, but about the solutions that I could provide.  That was the weekend that I decided to commit to the Microsoft stack of technologies.  It doesn't mean that I don't get to still play with cool technologies, platforms, and tools.  But it does mean that I take the language/platform variable out of the equation of my life.  The problems I tackle now are (to me) much more interesting: Sql vs NoSql, CQRS and DDD, platform integration, and solving previously "unsolvable" technology problems - just to name a few.  I plan on looking into Ruby and possibly ErLang, but frankly, I don't have the time.  Does .net solve all problems?  Absolutely not!  Do I still pay attention and participate in other communities?  Absolutely!  Where do I think you should take your career, and is your currently group doing the "right thing"?  Who knows!

The bottom line, one that has taking me a long time to figure out, is that if you want to do development "right" file for a business license and open your own shop (or become the lead in the organization that you love).  Otherwise, you will be spending a lot of frustrating days fighting an uphill battle.

[Sean Copenhaver]

Hey welcome to the list. I'll try to hit up on what you have said at another time. I'm thinking this might need to be split into a couple of threads.

--
You received this message because you are subscribed to the Google
Groups "ColaCodeDojo" group.
To post to this group, send email to colaco...@googlegroups.com
To unsubscribe from this group, send email to
colacodedojo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/colacodedojo?hl=en

--
“The limits of language are the limits of one's world. “ - Ludwig von Wittgenstein

"Water is fluid, soft and yielding. But water will wear away rock, which is rigid and cannot yield. As a rule, whatever is fluid, soft and yielding will overcome whatever is rigid and hard. This is another paradox: what is soft is strong." - Lao-Tzu

[Bryan Matthews]

True, most languages are not very different unless you start talking OO vs. functional.  At least the difference in language is secondary to the difference in frameworks, tools, and community.  For example, the ruby community seems to have made big waves over the last few years and have earned a reputation for rapidly developing new tools and techniques to solve problems and share with others.  On the other hand, .NET seems to have taken a lot of criticism in the past for lack of innovation and working in isolation.  It seems that may be improving, perhaps as a result of the criticism and awareness?

On Thu, Sep 29, 2011 at 11:03 AM, Bobby Dimmick <kr4...@gmail.com> wrote:

--

[Sean Copenhaver]

That could be a result of the flexibility and the values put on Ruby the language. My understanding is the underlying model is mostly simple (dynamic, meta object/class, message passing) but then they put a lot of syntactically sugar and shortcuts on top. Results in a language that values expressibility and esthetics. Look at all the DSL usage they have.

C# is a language that seems to value generality, rigidity, and explicitness. But that seems to be easy off with the additions of extension methods, type inferencing 101 (var keyword), and the dynamic type for the DLR being introduced (and what is nearly abandoned?). Although F# values very different things but they both compile to the same IL and use the same core libraries and both can do OOP.

All the framework stuff though I just am starting to dislike large heavy technologies. You'll spend too much time learning them or stumbling through them. Things move too fast and requirements change. If you have to invest a month into something you are less likely to consider moving off of it for something else as needs change. Smaller more targeted things are easier to pick and understand.

Anyway, I hope that wasn't all rambling. I'm getting very hungry.

--