Big Steps to Code Integrity
Typemock is making big steps towards its goal of code integrity.
Code integrity is what we consider the new paradigm of writing software. Moving the responsibility of code-correctness back to the developers. It is too easy to get sloppy and to leave it to the QA to find our bugs, thus developing without integrity and leading to waste in time and money. When developing with integrity, we are all responsible to make sure the code does what was intended to do.
We can reach to higher levels of code integrity, with automating unit tests, code reviews and management for excellence. We are helping teams do this by allowing developers to unit test their code, whatever design or technology they choose. Our new tool Racer allows validating Parallel Computing problems. This is a great step towards making our profession an engineering one, that we can be proud of.
Simple or Simply Terrible
I read the Lead Blog post: Simplicity.
Simplicity means the achievement of maximum effect with minimal means. - Dr. Koichi Kawana
I though that was the definition of Effectiveness.
I think that a better definition is: Clarity, Precision, and Ease
Once you are clear, precise and easy, you will probably be effective. That is what makes simplicity so hard, that is why we spend hours and hours discussing how to make our products simple.
The price of not trying
Twitter has been under a lot of fire when changing the replies policy, they still did the right thing.
They tried, if they wouldn’t try then they will be no way to progress and grow, if they become scared of user response, we will get a mediocre system.
Thanks for trying twitter and keep up the good work.
Isolate your ASP.NET – Race for Free Licenses
Our team is launching a new product for ASP.NET developers who develop
with integrity – the ASP.NET Bundle.
For the launch you can win FREE licenses if you are fast enough.
See our official blog with the detail on getting free licenses.
Good luck…
Scrum and Lean are just an excuse for our failing profession
To build the team that Typemock needs we need great developers. I don’t
mean craftsmanship or pragmatic developers, we need super stars.
Have you noticed that some developers are so much more productive then others? How can I make sure that Typemock created and attracts those kinds of developers?
As a profession we are still failing, take a look at the latest chaos reports, our numbers are worse. The number of startup and project that are failing is raising. What are we doing wrong?
Is Agile a process or an Excuse? There was even a session about this in Tech-Ed.
Perhaps we are not bold enough to leave our comfort zone, we just keep on doing those things that we where once good at, and this leads to mediocrity. Practicing one process will not make you a super star, be it waterfall or Agile. It will teach you how to do things in a different way and then enable you to crumble back to mediocrity.
We have to leave our comfort zone at all times, have a new challenge every day, commit to them, have integrity, raise the bar, try different things, focus on actions and not on results, dare to fail and stop waiting and making excuses.
Perhaps Integrity Management will help save our profession.
Clearing, the next stage
I
talked about the great effects of the clearing process that we do in Typemock. This process allows us to pinpoint areas that are not working, fix them immediately (by committing to controllable actions) and then to focus and celebrate on the things that do work.
Clearing is actually a state of mind. It turns out the people wait for the clearing to do the retrospect and to find solutions. But suppose you come to the standup with the solutions to your problems. Suppose you don’t only tell everyone about your problems but give 2 different solutions, you can even tell the team what you prefer. Just take 5 minutes before the meeting and come up with the solutions, wouldn’t it make the meeting more valuable. I think so.
If you can do that, why not go another step, why not find the solution yourself when the problem arises and they start executing your solution. You can then talk about it, in the “What is working” stage. This is how you can move your problems from the “What is not working” stage to the “What is working” stage, talk about it as a dilemma that you solved.
If we all do this, we can come to the meeting clear, we can solve it before the meeting, your manager does not need to be the bottleneck of solving problems.
Loosing sight
Because Managing by Integrity makes sure that we play
one game at a time, day by day, by creating controllable actions for each goal – we separate ourselves from the companies goals. This can lead to separation from responsibility. We did exactly what we said we would do, so we are in integrity, but there are no results.
For example, if we have a goal of finishing a piece of software but our controllable actions are to play foosball, we can be commit to playing foosball all day and be in integrity, but we won’t see any results.
This is not good, there must be a good balance between 200% responsibility and focus on controllable actions. It is everyone’s job to make sure that the actions we are doing do actually lead to the desired result. If in doubt, make sure that you are leaving your comfort zone and trying something new.
Travelling to the states
I will be travelling to Boston and Seattle from 22nd-28th of May. This is my first trip the the US since Obama was elected, I wonder if the atmosphere has changed.
I would be delighted to meet up with you in the evenings.
My mobile US number for this trip will be 347-244-2082
Follow me on TripIt to know where I am.
Converting Dynamic Types to Generic Parameters
There is a problem when an API uses a Generic Parameter as a Type reference.
Although having a generic parameter makes the code Type Safe
SafeType MyApi<SafeType>();
It is really hard to use the API in dynamic way. So if we receive a Type in a variable there is no easy way to call the generic method.
Type myType = GetTypeToUse();
var ret = MyApi<myType>();
// ^^^^^^ Error
One way to do this (convert a dynamic type to a generic type) is via reflection (See example on the Typemock Blog)
private static object MyApi(Type ofType) { MethodInfo myApiMethod = typeof(MyAssembly) .GetMethod("MyApi").MakeGenericMethod(ofType); return myApiMethod.Invoke(null, null); }
or we can cache the MethodInfo
private static MethodInfo myApi = typeof(MyAssembly).GetMethod("MyApi"); private static object MyApi(Type ofType) { MethodInfo myApiMethod = myApi.MakeGenericMethod(ofType); return myApiMethod.Invoke(null, null); }
When designing an API we should think of developers who receive the Type in a dynamic way, and have an embedded API to handle this from the start.
// Type Safe API
SafeType MyApi<SafeType>();
// Dynamic Type API object MyApi(Type ofType);
Flowers, Game Theory and our Company Culture
I had a great discussion the other day with a Professor who specialized in the
Game Theory. We had a nice discussion about flowers. Flowers compete for bees (guess why?) each flower can balance how much energy is put into its marketing (the colors, flowers, smell) and how much into its sales (the quality of the nectar). I really liked the discussion and some results are really interesting, for example, it is possible to predict which flower species thrive when they grow close to each other, and which fail.
But what really interested me was our discussion on Company Culture. The professor (who is also an investor and very much into business) put a lot of focus on the company culture. He told me that this is more important than the marketing or the product, because the marketing and product can change but the culture, the DNA of the company is very hard to change.
So what is the company culture of Typemock.
Off my head here are the values we value.
- High integrity workplace
(empowerment, teamwork, responsibility and accountability) - Getting things done attitude
- Strive for excellence and personal growth
- Customer-focused
- Learning by experimenting and measuring
Recent Posts
- Unacceptable: Unit testing will take 20 years to catch on
- The 4 reasons why we DIDN’T choose Oslo
- Typemock Academy Launch
- The First Rule to Software Craftsmanship
- Goal-driven Development
Categories
- .NET Tests
- Agile
- Code Integrity
- Community
- Debugging
- Fun
- Management for Geeks
- Marketing
- Product
- Release
- Reviews
- SharePoint
- TDD
- Time Management
- Uncategorized
- Unit Tests
Archives
- May 2010
- April 2010
- March 2010
- February 2010
- December 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- December 2008
- November 2008
- August 2008
- July 2008
- May 2008
- April 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
