I’m a .NET shop vs. I’m a Java shop parody

I’m a .NET shop vs. I’m a Java shop parody
November 26, 2012
Categories: Code Generation, CQRS, Model Driven Development, Software Development, System Integration, UML
Tags: , , , , , , , , , , , , , ,
by Jeppe Cramon

Saying that you’re a .NET shop, a Java shop or some other programming platform shop is just as ridiculous as if a software tester is saying that he is just a BDD man. Hopefully he is much more than that and has a more balanced approach to software testing, so he can select that test approach that makes the most sense for the problem at hand. Wouldn’t you be worried if you went to your car repair shop and were told that they’re only a piston shop?


If you define yourself and your approach to software development according to a technical platform then I fear for your future and your customers.

Being this limited in your software development approach will for sure cause you a lot of problems down the road because you’re limiting yourself too much.

Being a .NET or Java developer says nothing about how to use your platform/language skills. Mentioning a technology carries no promise that would assure me, as a customer, that you know how to tackle my problems.

It will still leave the following questions unanswered:

  • How do you analyze my problems?
  • How do you make sure that you have identified my core problems and don’t start tackling just the icing on the cake?
  • How do you assure me that the solution you will build is sufficiently well designed (separation of concerns, sufficiently small domain model that wont get me into all kinds of trouble, will be maintainable, etc.)?
  • How do you assure me that you know how to deliver a quality solution without essential bugs?
  • How do you assure me that my maintenance costs wont skyrocket because you hacked together a solution?

If you can tell me that you can draw upon many approaches, such as Domain Driven Design (DDD), Use Case analysis, Transaction analysis, Service analysis, Domain modeling, SOLID, GRASP, SOA, CAP, EDA, CQRS, Hexagonal Architecture, Model Driven Development (MDD), Specification by Example, BDD, TDD, Continuous Integration (CI), Agile, Lean etc. then I will start to believe that you’re balanced and will do your very best to pick the approaches and solutions that will work best for my particular problem.

My last hope is that you’re also pragmatic and wont go overboard and over-engineer a solution with a lot of unused or unneeded bells and whistles 🙂

As a wise man once said: “I hire for attitude and train for skills”.

 
Comments
Thomas Jespersen
November 27, 2012 at 09:13

If you tell me you can a have made god architecture based on all the mentioned acronyms, I know you are the over-engenering-type, that focus more on the technology and being bussword compliant than actually solving the customers problem.

I you tell me you have delivered successfully projects the last x years, and you only know one platform, I’m happy. Not because of your language, but because of your track record.

Reply
Jeppe Cramon
November 27, 2012 at 10:10

Thomas, there’s a difference between knowing and using 🙂
Is it bad to know a lot of Design Patterns? In my opinion No.
Is it bad to apply a lot of Design Patterns? In my opinion Yes, because they often end up causing more problems than they solve.

The list above focuses primarily on the mental approaches that focus on understanding the customers needs.
When you understand their needs, you will stand a much better chance of picking the right solution(s).
I’ve seen so many poorly designed projects, because people focus on technology first and fore most.
I want those that I pay to solve my problems to explain their attitude/mental approach before they explain their technology.

The technical part is mentioned to show that there’s so many ways to use your platform/technology and you should know as many of them to be able to choose the best design, which will hopefully be a minimalistic design that solves the problems best measured against time-to-market vs cost-of-maintenance in accordance to the customers wishes.
This means you need to know the cost and trade offs for all the technical approaches you hopefully have in your bag.

What I’m after in this blog post, is that you can tell me, as a customer, more than you’re using platform/language/technology X.
I’m requesting that you either show me (preferred) or tell me something that will convince me that you know how to deliver a good solution that solves my problems. Different problems calls for different solutions, so unless you can show me a Track Record that lists many happy customers, that match my profile and problems, then I would request you tell me more on how you would approach my problem. Just saying you do platform/language/technology X will not cut it.

Reply
Thomas Jespersen
November 29, 2012 at 13:02

Telling af customer that you can do: “Domain Driven Design (DDD), Use Case analysis………” is just as meaningless as saying you can do .NET, Java, Ruby or PHP.

Those “acronyms” does not show that you “… focus on understanding the customers needs”. It shows that you care more about the technology and architecture than solving the problem at hand.

I’m not saying that you should not use any of the mentioned methods/patterns/architecture… but your customer does not and should not care.

A customer needs to feel that you understands their problem, and the the solutions you propose makes sense. Also the customer would ideally get confirmations from other customers that you are reliable and fair.

Technically, all a customer needs to know is whether you can do Web development, Windows development, iOS Apps, Android Apps etc. And if you can write software that is maintainable, reliable, fast and can handle a lot of users. Throwing a bunch of buzzwords after the customer, will only scare them.

But your blog was arguing that .NET vs. Java was a bad measure when position your company. I agree… they are both capable of doing just about everything. All they need to know if what kind of software you can develop.

Save the buzzwords for when you look for new employees.

Reply
Jeppe Cramon
November 30, 2012 at 10:59

Thomas, I’m surprised you say that DDD and Use Case analysis is meaningless and that it doesn’t show a focus on understanding the customer needs. How can it be anything else than an attempt at trying to understand the customers needs?

The definition of DDD is: DDD is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains.
I think explaining to a potential customer how you will approach understanding their needs, before talking technology details, is essential. I will not sell them on the fact that I can do DDD, but I will explain them the process and the approach that I would suggest using for the project (given the understanding that I have of it).

The Crux of my blog post was, and I think we agree there, that technology X alone never will answer:
– How do you analyze my problems?
– How do you make sure that you have identified my core problems and don’t start tackling just the icing on the cake?
– How do you assure me that the solution you will build is sufficiently well designed (separation of concerns, sufficiently small domain model that wont get me into all kinds of trouble, will be maintainable, etc.)?
– How do you assure me that you know how to deliver a quality solution without essential bugs?
– How do you assure me that my maintenance costs wont skyrocket because you hacked together a solution?

What I was after is your mental approach first and foremost.
When you’ve explained that, then I would like you to explain how you will solve my non-functional requirements (that’s where technology/patterns becomes relevant and where Java, .NET or I do Web applications doesn’t answer this).

Reply
Leave a Reply

Recent Posts
Recent Comments
Categories