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 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
by Per Dervall
I’m sure you’re familiar with this situation, and if not, you’re either lucky or new: Starting a new assignment and taking over someone’s code, code that is in some sort of state of decay or disarray. Bonus points if the original author isn’t even around anymore to answer any questions you have. Extra bonus points if there’s no source control.
I’ve done this scenario quite a few times now, and the experience for me has gone from horror and bewilderment the first time I did it, to actually now enjoying it. As long as you have a proper and well thought through approach, I’m positive you can turn almost all code around.
What about rewrites then? It’s almost a mantra that if code is old enough it should have been rewritten. I’m sure there are times when this is the right choice, but it carries a very high risk. Going through code you sometimes find really odd pieces, which seems to do elaborate things for obscure reasons. Those, ugly as they may be, are sometimes gems of knowledge on how to handle specific corner cases. If you rewrite things, you will lose those gems. Another huge risk is the time when rewriting and you still have to manage the old system in addition to rewriting it. With features actually going in to the old stuff while writing new, and the split focus; you’re threading on perilous ground. Ask the Netscape guys, they should know.
So, refactoring is, in my opinion, the way to go in most cases. I’m going for the old-school definition of refactoring here – changing the implementation without altering the functionality. Don’t try to improve on what the thing actually does when you refactor. Just make it pretty on the inside. My approach to this is almost formulaic by now:
First off the bat, write tests for the existing code base – try not to change the code base too much. If any refactoring is to be done, it should be in order to increase testability. Aim for a coverage percentage you feel comfortable with, but don’t aim too high. As long as the coverage percentage doesn’t become a goal in itself – there’s quite a few horror stories about what has been done to increase code coverage. I remember hearing once about a guy who wrote a function that just iterated through every available function, calling it with null or 0 and ignoring the result and catching all exceptions. That sort of test is even worse than no tests whatsoever, since this leads to false security. Refactor the unit tests as well. I sometimes wonder why test code doesn’t get the same refactoring love that “normal” code does. It deserves it, test code is the only code that will find bugs instead of causing them.
Then refactor. The important thing is to not try to force the code into something it was never intended to be, say moving a webforms app to a MVC app while refactoring. That’s in the realm of rewriting, not refactoring. Instead, make it the best webform app you can. The point is to step-by-step make the codebase smaller, and thus more malleable. I usually find it easiest to work from the bottom up, starting with the data layer and ending up in the UI. As long as the refactoring never takes the form of scrapping an entire module of code, you should be able to continually have a working product throughout the process.
Use a good tool! I like ReSharper. Consider style warnings for your tool of choice as errors and accept no deviations. Spending time adding features like a keyhole surgeon to an uncontrolled codebase is producing waste and, more importantly, consolidating broken code.
That is just my two cents…
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:
- November 2014
- October 2014
- September 2014
- August 2014
- June 2014
- May 2014
- April 2014
- March 2014
- February 2014
- January 2014
- October 2013
- July 2013
- May 2013
- April 2013
- February 2013
- November 2012
- October 2012
- September 2012
- August 2012
- May 2012
- April 2012
- January 2012
- December 2011
- November 2011
- September 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- November 2010
- October 2010
- August 2010
- July 2010