Posted by Igor Moochnick on 06/02/2012
Just read an amazing piece from Joel Spolsky where he describes his own unique style of management. I could agree more. It’s the best description I ever heard about how to make successful teams:
“Stop thinking of the management team at the top of the organization. Start thinking of the software developers, the designers, the product managers, and the front line sales people as the top of the organization”
It is so true – when you hire smart people, let them do what you’ve hired them for. Self-organizing teams, that we’ve all learned about from the Agile practice, can work ONLY when you hire smart people. If your teams are not successful and not self-organizing – check the root cause: are you sure you hired the right smart people?
Organizations can scale successfully and move forward ONLY when the sub-pieces of the organization can be self-directing. The management exists ONLY to provide general message, coordination and support for the employees (removing impediments).
Posted in Agile, Thoughts | Leave a Comment »
Posted by Igor Moochnick on 06/15/2011
Thanks for everyone attending the Architect Factory last week, especially everyone that attended my presentation. Great participation and great questions – Thanks.
As promised – below are the slides from the talk:
P.S. I’m still trying to figure out what happened to the video recording of the session. Will update the post as soon as the issue will get resolved.
Posted in Agile, Alt.Net, Peer Code Review, Presentations, Refactoring, Training | Leave a Comment »
Posted by Igor Moochnick on 06/05/2011
Currently in the Software Industry there is no such thing as an “Architect Certification”. Yes, I know, that there some that claim to be like OCM (Oracle Certified Enterprise Architect/Master) or MCA (Microsoft Certified Architect), but they are concentrated on a certain technology or certain aspects of an architect.
In my opinion, to be an architect means that you should be a generalist enough to know a wide range of technologies (not only .NET or Java) and to be able to make an educated decision when and how to use them.
Pick a right tool for the job!
An architect should be bold and well spoken and be able to convey his/hers opinion to the team, the company and the management. He should not rely on his old achievements to support his “respect”. He should be able to defend his ideas at any moment of time by providing a reasonable explanation and a proof that the chosen way is the best one at this moment of time.
In simple words – an Architect should be “Bull**it-free” (an opposite to “full of bull**it”).
The only way to certify a person to be a “Bull**it-free” is to put him on a spot in front of a large audience with a wide variety of knowledge , technologies and experience and let him defend his decisions. This is the best way to see what this person worth.
So, if you want to be a great Architect, get out there, start contributing to the community. Start with the local user groups and continue making your way up to the conferences. Get visible!
What do you think?
Posted in Agile, Architect, Thoughts | 2 Comments »
Posted by Igor Moochnick on 05/29/2011
It is essential to talk about the Lean teams and not only about the Lean companies. Let’s be realistic – most of the current companies are not Lean. I predict that it’ll take a whole generation for software companies to shift from the “old ways” to the “new ways” of Software Development and there is not a lot we can do to change this dynamics. It takes a lot of effort to persuade the current management generation that the “new ways” are much better than the “old ones”. Usually the conflict lies in the “ego” world – whose “ego” is bigger.
One of the principles of Lean Software Development is to “Respect People” or, sometimes it’s reads as, “Empower People”. This directly contradicting the “old ways” where the principle was 100% opposite – the strict “top down” management and control. The “top down” development was a result of that principle where the top level requirements were translated into the top-down architecture which, in it’s order, was translated into a components with a strict plan of dependencies and schedules.
In my personal opinion this principle should be at the second place following the very first and essential one “Eliminate Waste”.
Let’s see what this principle is about and why I see this is one of the core ones:
- It’s all about Training:
- Training is essential to increase your team’s potential.
- The team should be a self-sufficient, self-organizing and self-managing organism.
- The people should be trained to the point where they can get a requirement and deliver.
- The right training will ensure that the delivery is up to your standards, up to industry standards and contains all the necessary artifacts (i.e. documentation, architecture, testing, installation and configuration instructions, etc…)
- Move responsibility to the lowest possible level:
- Developers are much closer to the “metal” and to the technology.
- They know more about the technological problems that may arise during the development process and they can foresee the conflicts in the requirements.
- Encourage pride in craftsmanship:
- Encourage people to be passionate about what they do and how well they do it.
- Encourage the team to get evolved in the community or, at least, in a cross-team communication. Make them share the ideas and present their achievements.
I hope, the points I’ve discussed above, make pretty compelling explanation why we have to Empower the teams and the people. If you still not convinced and you’d like to ask a usual question: “Why do we need the management and the managers”, I’ll give you my favorite answer: “To empower people, to make them succeed and to provide them with all the support they need to fall into the pit of success”.
The managers should:
- Remove impediments
- Resolve conflicts
- Catch errors
The managers should never:
All the above is very well summarized by a very old aphorism: “Find good people and let them do their job”. If you, as a manager, found right and smart people – they’ll do the right job. If the people are not “right and smart” – then why were they hired in the first place?
Posted in Agile, Community, Lean, Thoughts, Training | Leave a Comment »
Posted by Igor Moochnick on 05/12/2011
Finally got around to clean up the slide deck and improve the presentation flow. Please enjoy the “Best Practices for the Agile Design”.
Posted in Agile, Composite Applications, Continous Integration, Organization, Presentations, Thoughts, Tutorials | Leave a Comment »
Posted by Igor Moochnick on 05/09/2011
This weekend we had Boston CodeCamp. Even though the main site for Boston CodeCamps (TheDevCommunity.org) is under construction and major overhaul – the event organization was as smooth as ever. Thanks for all the organizers and attendees.
The two sessions that I ran had a good attendance and a good flow of questions – thanks for everyone who joined!
As promised, I’m going to publish the slides and the source code.
Demo application source code – on my SkyDrive.
Posted in Agile, Caliburn, Composite Applications, MVVM, Presentations, Tutorials | Leave a Comment »
Posted by Igor Moochnick on 04/12/2011
A week ago (Sat 4/2/2011) gave a presentation about tips, tricks and best practices that can greatly help you to build products with the distributed teams.
Thanks for the organizers of the ProductCamp (http://productcampboston.org/) and all the attendees for making a great event.
Posted in Agile, ALM, Community, Composite Applications, Continous Integration, Design, Kanban, Organization, Presentations, Thoughts, Tutorials | Leave a Comment »
Posted by Igor Moochnick on 03/27/2011
1. Install a new build agent (uncheck the Windows service) on a different port and a different path.
Ex: ownPort = 9092
2. Change the buildAgent.properties file:
3. Add a Windows service for the build agent:
sc create TCBuildAgent2 DisplayName= "TeamCity Build Agent Service2" start= auto binPath= "C:\TeamCity\buildAgent2\launcher\bin\TeamCityAgentService-windows-x86-32.exe -s C:\TeamCity\buildAgent2\launcher\conf\wrapper.conf wrapper.ntservice.account=
If you’ve installed the agent to run under non-System credentials your password will be written in the registry in plain text. Don’t forget to remove it from there.
Posted in Continous Integration, TeamCity | Leave a Comment »
Posted by Igor Moochnick on 03/14/2011
Other posts in the series:
- Can TFS be useful if the sources are in Subversion (SVN)? Or how to run integration and nightly builds on TFS from SVN?
- Teaching TFS custom activity to work with the Svn, Cvs, Git and other source control command line tools
Obviously you don’t want to expose your password to everyone who can see the build definitions. For this I can suggest 2 separate solutions – the simple one and the right one.
If you want it quick – implement Password as a string workflow parameter but do not put the value in the build definition (this is visible to everyone) but, in the metadata, set it’s availability to “Always Show the Parameter”. By this you’ll ensure that the password will be available for you to set not only during the build definition but, as well, when anyone will be scheduling it for the execution.
The better way, as I found out, is to create a custom “credentials” construct (type). This allows you to have your own editor for the password (where you can have it masked) and to control how it appears on the build definition.
The final result should look like this (notice the “Credentials” parameter):
Continue reading for the implementation details …
Read the rest of this entry »
Posted in Agile, ALM, Source Control, Subversion, Svn, TFS, Tutorials | Leave a Comment »