by Örjan Sjöholm
We love Knowledge Sharing! However, going to conferences like Leetspeak isn’t part of our daily work. Code crunches and weekend hackathons are nice activities but they just aren’t feasible for everyone.
How can we keep ourselves up-to-date with the latest observations in our field, during an ordinary week?
We can read blog posts or books, watch screencasts from sites like Tekpub, help other developers at Stackoverflow, or join an OSS project.
All these activities require our spare time or sanctioned knowledge development, so how can we make some room for knowledge sharing within working hours?
Together with our teammates, we can combine a lunch with watching a recorded seminar or talking about new findings. Hopefully we’ll continue to discuss the topic and maybe adapt some of the new things we have learned.
12:00 the 15th of May we’re hosting a Global Code Lunch at our customers’ sites. The idea is to inspire people to search for knowledge together, not only in their team but together with the whole community. So if you find this interesting, join us and tweet your findings with the hashtag #code-lunch
by Martin Mazur
I find that people are preoccupied with history. Always looking back and referencing the past to make decisions about the future. One important fact to remember is that it is just that – history. What I mean by this is that the events we are reflecting on occurred in a context which is very different from our current situation. The processes we wrote, the work we did, the technology we used has eventually become stale. Everything has a shelf life simply because time moves forward and the context changes.
Don’t get me wrong, we need to learn from our past, especially our past mistakes. You can learn from history and use it to come up with new ideas, not just re-apply the old ones. Even if something had a certain outcome a year ago, the context may be radically different today and that will make the outcome radically different. Basically you have to respect history when creating your future but you shouldn’t obsess about it.
Working like this is a scary idea for most. It’s scary because we are afraid of the unknown, and the future is unknown territory. I think this is one of the reasons we try to project the past onto the future. We try to minimize variations, completely ignoring that we have a huge variable called ‘the world’ which we can’t control.
Here at tretton37 we understand this, and that’s why it’s so important for us to continue questioning and re-evaluating our approach and ideas – not falling into the trap of “That’s how it’s always been”. With this in mind, we explicitly chose “Challenge the World” as one of our core values. By challenging notions of what we can and can’t do, we continue improving and innovating ourselves. It allows us to try new things and uncover new ways of nurturing people, teams, software and business.
I’m not saying that we should question everything all the time. I’m saying that we need to understand the “Why” and “Why not” of the things we do and ideas we have. If either of those reasons change or we don’t agree with them, we have justification in challenging that idea. Since we carefully evaluate the reasons behind our ideas, we feel secure with this type of controlled innovation.
We feel confident in calling our company tretton37 and ourselves ninjas. Because why shouldn’t we? Some may say we don’t take our work seriously but our opinion is that being serious and boring are two separate things. Historically they go hand in hand, but why not separate them? Can’t we have a bit of fun while developing serious software? We take our profession very seriously – we just don’t feel that we have to be boring in order to do so.
It was also quite a leap of faith for us to create a high quality and affordable conference. When we couldn’t see the reason for why there shouldn’t be one, we challenged the notion of the huge, classic conferences. Does it have to be expensive? Can we make it affordable, awesome and high quality? We thought we could and we think that we succeeded.
These are only some examples of how we’ve challenged historical notions in our industry and we are by no means intending to stop.
by Joel Sannerstedt
Last week, three of us from tretton37 in Lund had the opportunity to, along with two guys from a telecom company in Copenhagen, attend Dan North’s two-day masterclass, Faster Software Delivery. The class was held at Foo Café in Malmö which is an independent meeting place for people within the IT industry in the Malmö/Lund area in the south of Sweden. Foo Café is located in Media Evolution City, which is a nice place for this kind of event. In addition to that, the coffee and food served were great. (On a side note, it was really interesting to see six software guys trying to set up the AV in a meeting room)
Listening to Dan North for two days was a really positive experience. We had great discussions during the course and we received a lot of very good and useful information with many a-ha moments.
Many of the discussions spun around Dan’s Patterns of Effective Delivery, how to create and deliver software faster. One major theme in this, is what Dan calls unpacking the agile hype. Agile has been very effective in comparison to development in the pre-Agile era, but what we need to do now in order to take the next step, is to challenge these practices. Instead of using each technique and adapt each practice, we need to ask ourselves, what are we optimizing for? What is it we’re trying to achieve by using this specific technique? And what could be doing instead? During the course, each question was discussed thoroughly and different answers proposed. Trying to retell these are well out of the scope for this post, but there are a few talks by Dan on the subject available on the interwebz.
// Joel, Per, Stefan
by Björn Johansson
On the 17th of May we had Roy Osherove to come to our office in Lund and give us an advanced TDD course. Roy did an introduction where he talked about the differences between mocks, stubs and fakes. He followed up with some different isolation frameworks, both proxy and profiler based. It was really interesting to see the different syntax the frameworks are using. It was especially fun to do some exercises and being forced to use another framework than you are used to work with.
Roy continued to show different techniques and patterns for refactoring legacy code so that you are able to test it. A lot of legacy code is filled with statics and dependencies – all getting in your way when you just want to fix one little issue. How nice it would be to be able to write a unit test for that piece of code without have to change too much code? Who hasn’t been in a situation like that?
It was a day filled with lots of tips and tricks and other useful information. Add some good discussions as well and we had an awesome day. We at tretton37 are really looking forward to have Roy visit us again soon!
by Peter Ekerot
We at tretton37 never do anything half arsed. We’re into SharePoint and we mean it. We are ninjas, even on SharePoint!
I firmly believe that SharePoint is truly ninja. What other system is awesome for collaboration straight out of the box, useful as a content management tool, has document versioning and workflows, can calculate large spreadsheets, batch convert documents, or integrate with obscure backend systems? SharePoint can do all of that and much more.
SharePoint can exist on its own servers, be it real ones or virtual but it can also exist at Microsoft Data centers; courtesy of SharePoint Online.
SharePoint has evolved over the course of more than ten years. Many of the core concepts that where there from the beginning are still there. Some of the refinements in the latest installment are an enhanced enterprise search (especially with FAST), a rather impressive “My Site”, and a very useful taxonomy (tagging) system.
SharePoint is also a large and extensive development platform. It can solve business problems, and a rather full range of business problems at that.
However, there are some dark clouds in the otherwise blue skies of SharePoint. It does not excel as a content management platform for public-facing internet sites without some deep thinking and special implementation details. It is not very mobile or tablet friendly out of the box, although some of the recent cumulative updates have addressed some of the problems, among other things.
So, where is the ninja stuff?
SharePoint as a development platform is huge. The foundation is .NET Framework 3.5, which might not be the latest and greatest but does the job. There’s Business Connectivity Services (BCS) to connect to any other system imaginable, either using WCF services or custom code – giving great integration possibilities. With the Client Script Object Model (CSOM) and custom tools like SPServices, one can build really nice, productive and fluid user interfaces on top of SharePoint.
As with any platform one needs to work with the grain of the fabric when developing SharePoint. What’s different from other web technologies or frameworks like ASP.NET MVC is the sheer size of the fabric we have to work with and the rather steep learning curve. Building properly on top of SharePoint requires a very good understanding of how the platform works and what parts to use for what purpose, and believe me; there are many parts. Beyond that developer tooling may sometimes be tedious at best. For instance one needs a full server installation just for development, which makes development start-up time for new projects significantly longer than with other web technologies.
The ninja part comes with deep experience in developing for SharePoint, choosing the right approach for the problem, applying standard features or custom development. A problem can often be solved in one of many different ways, it takes a ninja to know the right one.
And this is just for developing solutions. There’s room for much more under the SharePoint flag; Configuration management, Infrastructure, Integration, Security and more.
On the topic of SharePoint and ninja or not, I think the following piece by Mark Rackley is explaining it rather well, especially the twitter quote:
“@mrackley: Here’s an interesting question. Is it possible to be a “Junior Architect” in SharePoint? I think by its nature it’s a senior position.”
“@cmcnulty2000: I once met a junior surgeon. Didnt use him though. (my favorite response)”
There are so many facets of SharePoint solutions and development that a single person can’t really know it all (except some people – but a select few have cleared that certification).
Want to know more? Send me an e-mail or leave a comment
About this blog
We at tretton37 believe in having a strong company culture that promotes craftsmanship, professionalism and knowledge sharing.
We want to use this blog to share what we know and give everyone insight into our thoughts.
Here is the RSS link for this blog: