Recently a colleague and I had made a strange discovery. We both worked at a previous software consulting company where we worked with another person there. She was decent enough and assisted us on two of our projects at the end of their life cycle, which required small enhancements and maintenance. I was the team lead on the projects and responsible for architecture, design and construction. My colleague was the lead developer on the one project.
We discovered recently that she (the other developer) decided to take ownership of our code and enter it into 'My Dot Net Story' competition on her own behalf. Added to that she came second and won some prizes. On top of that she was interviewed by the guys from dotnetrocks which I admire greatly.
Now, my colleague is more upset than me. I am not concerned about the prizes but the fact that she was interviewed on dotnetrocks and took all the credit really disturbes me. The guys interviewed on dotnetrocks are reserved to the ranks of Robert C. Martin, Greg Young, etc.
How do you trust someone like this in the future? I know that my colleague and I will never work with her again because of this. Software development is a very small industry in South Africa. To burn your bridges that early in your career is not a wise choice.
In engineering we had compulsory ethics courses you had to complete and pass. To consider ourselves as professionals we should be following those ethics to the tee. To break those standards of ethics is to lose the trust of your fellow collegues and your employers.
Any other profession has a board that you have to report to. This applies to law, engineering and medicine. This gives the professionals a buffer to avoid any liabilities and also protects the employers to know that the professionals are required to be at a certain professional level. I really wish we could incorporate something like that into our industry.
Sunday, January 31, 2010
Monday, January 25, 2010
A week with Greg Young
We have had the priviledge last week to spend some time with the Greg Young. We had four mind blasting days which consisted of him blowing our minds all over the floor with his concepts and ideas :).
For the first two days he covered his Command Query Resposibility Segregation (CQRS) architecture. For those of you that are familiar with the Command Query seperation pattern, he applies this on an architectural level. In summary he believes that your "write" domain and your "read: domain will always remain in conflict because they will always have different requirements. He believes that you should keep those two domain seperate.
The "write" domain contains all your entities and values objects with all your business rules. This domain provides your business value for your company. The domain expects various input commands and will generate one or many events from those commands. These events will then be routed to an Event Store (which sole responsibility is to store the events) and any other domain interested in those events. This can of course be done synchronously or asynchronously. The async part of course involves more obstacles to overcome but has many benefits as well.
The "read" domain consists of all your DTOs and fullfills your reporting needs in your domain. This domain will typically read from an OLAP store, covert in to DTOs and send it to the UI.
Greg also explained various architectures we can use and how to address many of the architectural pitfalls that you might come accross. He also discusses other interesting topics like Charding and load balancing techniques.
For more information on CQRS, you can view this blog which has a very nice article and source code you can follow.
The second part of the week, Greg gave us a lot of consulting advice surrounding the trading domain. Luckily for us he comes from that domain and has written a very highly scalable system for statistical analysis. He went through his architecture and domain model and also a lot of the pitfalls they encountered while developing the system. Hopefully this will help us avoid similar pitfalls in the near future.
For the first two days he covered his Command Query Resposibility Segregation (CQRS) architecture. For those of you that are familiar with the Command Query seperation pattern, he applies this on an architectural level. In summary he believes that your "write" domain and your "read: domain will always remain in conflict because they will always have different requirements. He believes that you should keep those two domain seperate.
The "write" domain contains all your entities and values objects with all your business rules. This domain provides your business value for your company. The domain expects various input commands and will generate one or many events from those commands. These events will then be routed to an Event Store (which sole responsibility is to store the events) and any other domain interested in those events. This can of course be done synchronously or asynchronously. The async part of course involves more obstacles to overcome but has many benefits as well.
The "read" domain consists of all your DTOs and fullfills your reporting needs in your domain. This domain will typically read from an OLAP store, covert in to DTOs and send it to the UI.
Greg also explained various architectures we can use and how to address many of the architectural pitfalls that you might come accross. He also discusses other interesting topics like Charding and load balancing techniques.
For more information on CQRS, you can view this blog which has a very nice article and source code you can follow.
The second part of the week, Greg gave us a lot of consulting advice surrounding the trading domain. Luckily for us he comes from that domain and has written a very highly scalable system for statistical analysis. He went through his architecture and domain model and also a lot of the pitfalls they encountered while developing the system. Hopefully this will help us avoid similar pitfalls in the near future.
Thursday, January 7, 2010
Software Craftmanship
I listened to a dotnetrocks podcast yesterday with Corey Haynes on Software Craftmanship. This was a very inspiring and insightful podcast.
He was explaining that he is setting up a learning institute in the US to start involving students with actual live company projects. I think this is a great idea. Our industry is really shocking with no real mentorship and guidance for new programmers trying to get into the market.
I have discussed it with my colleagues and boss and we have decided we are going to implement an internship program here at Media24. This will be between 6 months and a year. The goal is to get fresh graduates from college and varsity and groom them into our fields.
We will be selecting non critical projects that are nice to have for business and the interns will work on them. They will take ownership of these projects and with guidance from mentors drive these projects to completion. This is beneficial to business because they are able to complete more projects at a very low cost.
This process will take the interns from apprentice to journeyman and give them a good opportunity for career growth. We will, at the end of the process, select candidates to join our team and the other candidates will walk away with numerous projects on their CV and be at a certain level in their profession. They will also have the benefit of working in the financial sector which is always difficult to get in to.
We are fortunate enough to have a very senior team at our company and have a lot of knowledge to draw from. We also have a new architect joining our team next week which has tons of experience in the mentoring and best practice field. He worked for a company called BBnD in Cape Town and has literally written their book on best practices and mentorship. We will rely on him quite a lot to get this process started.
We have further ideas of where we want to take this but I hope that this for now will at least help new developers in the industry and give them the much needed opportunity.
He was explaining that he is setting up a learning institute in the US to start involving students with actual live company projects. I think this is a great idea. Our industry is really shocking with no real mentorship and guidance for new programmers trying to get into the market.
I have discussed it with my colleagues and boss and we have decided we are going to implement an internship program here at Media24. This will be between 6 months and a year. The goal is to get fresh graduates from college and varsity and groom them into our fields.
We will be selecting non critical projects that are nice to have for business and the interns will work on them. They will take ownership of these projects and with guidance from mentors drive these projects to completion. This is beneficial to business because they are able to complete more projects at a very low cost.
This process will take the interns from apprentice to journeyman and give them a good opportunity for career growth. We will, at the end of the process, select candidates to join our team and the other candidates will walk away with numerous projects on their CV and be at a certain level in their profession. They will also have the benefit of working in the financial sector which is always difficult to get in to.
We are fortunate enough to have a very senior team at our company and have a lot of knowledge to draw from. We also have a new architect joining our team next week which has tons of experience in the mentoring and best practice field. He worked for a company called BBnD in Cape Town and has literally written their book on best practices and mentorship. We will rely on him quite a lot to get this process started.
We have further ideas of where we want to take this but I hope that this for now will at least help new developers in the industry and give them the much needed opportunity.
Clean Code
First of all, apologies for not blogging for so long. Been very busy on launching a technical analysis and trading platform.
I have, at last, over the holidays had some time to catch up on some reading. I am in the latter part of Clean Code by Robert C. Martin and I am very impressed with it.
Uncle Bob is truly the expert on Agile programming and his book is a clear guide on how clean code should be written. He keeps it very engaging and on your toes. He explains all the necessary concepts in the first part of the book and then shows very good examples of applying it as well in the latter half of the book.
Also, throughout his book he has very important points that he lists. Two of them which I will swear by is his famous SOLID principles and also Kent Beck's principles on creating good tests.
I have been comparing the book with Code Complete by Steve McConnell and both are very good reference books for code reviews. I would suggest people choosing between these books to first go for Clean Code because it is very engaging and has good practical examples and then get Code Complete as reference material. Code Complete's strong point is that it has very very good statistical information and is truly a complete book on coding standards.
I have, at last, over the holidays had some time to catch up on some reading. I am in the latter part of Clean Code by Robert C. Martin and I am very impressed with it.
Uncle Bob is truly the expert on Agile programming and his book is a clear guide on how clean code should be written. He keeps it very engaging and on your toes. He explains all the necessary concepts in the first part of the book and then shows very good examples of applying it as well in the latter half of the book.
Also, throughout his book he has very important points that he lists. Two of them which I will swear by is his famous SOLID principles and also Kent Beck's principles on creating good tests.
I have been comparing the book with Code Complete by Steve McConnell and both are very good reference books for code reviews. I would suggest people choosing between these books to first go for Clean Code because it is very engaging and has good practical examples and then get Code Complete as reference material. Code Complete's strong point is that it has very very good statistical information and is truly a complete book on coding standards.
Subscribe to:
Posts (Atom)
