Interview with Rafeeq Ganayi, Technology Architect at Accenture
Question: What were you expecting before seeing M# in action?
When I heard of M# first I thought it would be just like the other code generators I had tried and abandoned in the past.
My concern about code generators in general was that they produce a huge amount of dirty code and don’t follow best coding practices. For example they put data code in UI layer and fail to provide any support for proper automated testing. I found them counterproductive in the long run.
I was keen to see if M# is going to be actually different.
Question: How did you test / evaluate M#?
I don’t believe talking about a technology can show its real strengths and weaknesses. So to evaluate M# I took a real life scenario that was a small yet complex application which we developed recently at Avanade.
It constitutes of about 5 web pages one of which is a complex report, merging and showing data from 6 database tables, another as a complex multi-master-detail data entry form, etc. We developed that using Visual Studio in just over a week.
The same application was built from scratch in M# while I was watching and participating during the evaluation session. We built the whole same functionality in under an hour which was incredible.
Question: What steps did you take in assessing the generated .NET code?
I looked at the generated .NET code, SQL tables and data access code, business logic layer, Unit tests, UI mark-up, etc. I found the entire generated .NET code to by fully compliant with standards. It was documented, clean and with test code coverage.
It was nothing similar to what I had experienced in trying other code generators. If I had first seen the code I probably wouldn’t believe it’s machine generated.
Question: What was your impression of M# immediately after the evaluation?
I was simply amazed. Writing all of that code manually [without M#] would need a big chunk of money spent on development and testing. Specially getting to a bug free stage is no easy task and would involve several round trips between the developers, testers and users.
Speed, quality and efficiency were the most impressive features about M# to me.
Question: What kind of companies would you recommend M# to?
I believe all kinds of companies can immensely benefit from it when developing web based applications as it takes away the overhead of writing and maintaining large volume of .NET code by encapsulating that in a few lines of [M#] code.
I wouldn’t say cost and time are the most important factors for all projects out there, but for many it is. If you want your project to be delivered rapidly without compromising on quality, and at the same time want to have all that flexibility to customise and extend the functionality then I believe M# undoubtedly would be a great tool.
Question: What impact do you think M# will have on testability of the end result?
It’s my number 1 favourite thing about M#.
The way M# has adopted automated testing approach for both unit and integration is commendable. You can define test source to represent the end system easily using a data-management UI while designing the system. Then all that is available in the code, with full Intellisense, as if you had programmed your test data. It makes authoring of the actual tests ten times faster.
Not only can you rapidly unit test your code but you can also enable automated integration testing with just a few lines. You can simply configure data source to represent end system and have your code tested against that without getting into the nitty gritty of writing mocks/fakes. Although you can still write your own mocks/fakes if you want to, for example when testing against external systems that might be unavailable during testing.
Question: Where do you think M# stands based on the current industry standards?
When you use M# it enforces standardisation and adherence to the rules. It has a built-in rules engine which will keep watching your code warn you when do something that can lead to problems later on.
From the process perspective I would say it is hand in hand with Agile, TDD and BDD. In particular if you do Agile, then M# can be a game changer as you can have your user stories workshop in the morning, and show the developed system to the users for testing and feedback in the afternoon, instead of spending days to do the same. That will increase the project success rate and user satisfaction enormously.
Question: How difficult do you think it will be for a .NET developer to learn M#?
Something I found very useful is that M# provides you with a side-by-side view of the generated .NET code so you can see what .NET code it is yielding from your M# code.
One problem many people have with code generators is that there is a gap between the development code and run-time code that you must debug. That disjoint makes the process frustrating as you have to keep switching your mind between the two.
When using M# the joy of development is not taken away from you.
Question: Any summary or conclusion?
M# has that WOW factor not just because it can make you a lot faster but because it doesn’t sacrifice quality and flexibility in doing so.
It fits in very well with the modern methodologies and processes like BDD, TDD, Agile etc. Architects can use M# to define the code architecture while developers then use it to quickly develop and add the functionality and test engineers can use M# to quickly write and run the automated tests.
No longer do you have choose to between “Rapid” and “Proper” development as with M# you get both. You use a mix of M# IDE and Visual Studio when developing, and end up with maintainable standard .NET code you can be proud of.