We love SMS!

Recommendations

Info

18 © Ollyy / Shutterstock.com tic, with desks that can move around, WiFi, and absolutely no cubicles. • Enforce immediate sharing of knowledge: everyone publishes their work as it develops. The rules should allow others to copy and reuse that, but under reciprocal conditions. Even internally in a company, code should be remixable to ensure that there is full competition. • Allow anyone to start a new project, at no cost and no risk. Make sure the technical infrastructure allows this. Starting a project means being responsible for it. Most projects will fail, which is fi ne if the cost of failure is very low. • Ensure that projects are structured in a clear overall architecture that can be learned quickly. Slice your architecture into two or three layers, and group projects into layers. Defi ne the contracts between layers (APIs and protocols) ruthlessly but don't try to define how particular implementations work, as long as they respect those contracts. • Defi ne good criteria for success, and apply these to projects so that it's clear which projects are winning. It could be number of downloads, number of dependent projects, etc. Make winning this a primary and fun "goal" for teams, so that it becomes more important than fi nancial reward. • Make it easy for newcomers to start contributing to projects, and make sure there are always more challenging projects they can move on to. Smart people enjoy learning, so make work a continuous learning experience. • Be prepared to drop individuals who are unable to build or join successful teams. It doesn't really matter how smart an individual is, the unit of success is a team, and it's better to have three ordinary people who work well together than one super-smart guy who can't work with anyone. • Enjoy yourself at work, and infect your staff with the same sense of enjoyment. Laugh at yourself often, it makes others feel at ease. To conclude, many of these lessons may be obvious, but put together, the changes can be radical. We've done this in several projects now, and turned exhausted, unfocused teams into little powerhouses producing brilliant products. It's dogmatic in Social Architecture: the same people, organized differently, can be 100 times more effective. Pieter Hintjens is the author of "Code Connected" (Volume 1), the new O'Reilly book on ZeroMQ, and the founder of the ZeroMQ community. He's lead developer on the Zyre and CZMQ projects. His in-progress book on the digital revolution is on SoftwareandSilicon. com. In 2005 he designed the original AMQP (Advanced Message Queuing Protocol) specifi cation. From 2005 to 2007 he helped organize the fi ght against software patents in Europe. He's been CEO of iMatix since 1996. He drums with a West African group in Brussels, is a certifi ed pistol instructor, and has three lovely kids. The one religion he invented (Stallmanism. org) died when the beer ran out. MovInG froM C++98 to C++11 rvALuE rEfErEnCES, MovE SEMAntICS, AnD PErfECt forWArDInG effective c++11 Programming Software developers familiar with the fundamentals of C++11 are ready to advance from knowing what’s in C++11 to understanding how to apply it effectively. This seminar, based on information in Scott Meyers’ forthcoming Effective C++11, highlights the insights and best practices of the most accomplished C++11 programmers: the things they almost always do (or almost always avoid doing) to produce clear, correct, effi cient code. Scott Meyers 2 DAyS trAInInG 10 JunE, oSLo 17 JunE, LonDon LAMBDA EXPrESSIonS SECrEtS of tHE C++11 tHrEADInG API SMArt PoIntErS The seminar is based on lecture presentations, with ample time for questions and discussion by attendees. There are no hands–on exercises, but participants are welcome – encouraged! – to use their C++ development environments to experiment with the ideas in the seminar as they are presented. 10 JunE. Venue: Radisson Blu Plaza, Oslo 17 JunE. Venue: Holborn Bars, London SCOTT MEYERS Scott Meyers is one of the worlds foremost experts on C++ software development. He offers training and consulting services to clients worldwide. Scott wrote the best–selling Effective C++ series (Effective C++, More Effective C++, and Effective STL) and orchestrated their initial electronic publication (originally as Effective C++ CD, subsequently as DRM–free PDFs). Hes also author of Overview of the New C++ (C++11) and Effective C++ in an Embedded Environment. Scott founded and is Consulting Editor for Addison Wesleys Effective Software Development Series, and he conceived the boutique conferences The C++ Seminar and C++ and Beyond. He received the 2009 Dr. Dobbs Excellence in Programming Award. A programmer since 1972, he holds an M.S. in Computer Science from Stanford University and a Ph.D. from Brown University. OSLO - www.programutvikling.no LONDON - www.developerfocus.com
© Ollyy / Shutterstock.com 20 trAnSItIonInG SuCCESSfuLLy froM tHE It SIDE to BuSInESS: 5 questions every developer should ask before embarking on a BA career By Howard Podeswa I recently had a conversation with my son, who is just entering into the field of Big Data analytics with an up-and-coming startup and it brought me back to my early days as a programmer/analyst in a scrappy software development company. It got me thinking about the direction my career has taken since those times and the many paths his career might follow. I’ve gotten to know one of those possible paths quite well - the route from IT to Business Analysis - due to my role as CEO of Noble Inc., a Business Analysis training and consulting company – and because I have walked that path myself. This article is for anyone who is personally contemplating that transition, or is in the midst of it. I want to explore why someone would seek this path, what the impediments are and offer some suggestions for how to transition successfully. BEnEfItS of A trAnSItIon froM It to BuSInESS AnALySIS The Business Analyst (BA) function is to facilitate communication between the business and the solution provider; it may be a formal, dedicated role or a function played at times by a team member. In my work with my company, Noble Inc., I‘ve met many developers around the world who are making the transition to business analysis - and heard many explanations for why they were motivated to take that route. As someone who has successfully navigated the transition, I have also shared many of these motivations: I went from being a programmer who chose the profession because I was being paid to ‘play’-- and who couldn’t care less about business -- to being a BA who now runs a business as CEO of Noble Inc., and who is comfortable sitting with CEOs and VPs of large corporations, negotiating deals and helping them improve the BA practice in their organizations. From these perspectives, I’ve seen the following reasons for making the transition from IT development to business analysis: • Ability to leverage experience: Experience comes as a blessing and a curse if you are an IT developer. As you build your experience, coming up behind you are programmers who are more up-to-date on the latest technologies, who work faster and are willing to work longer. A BA role gives you a chance to leverage the skills you’ve accumulated over the years in a profession that highly values experience and maturity over technical wizardry. • Burnout: You spend years getting paid to ‘play’ and enjoy ever-novel technical challenges --- when one day you just don’t feel the love anymore. Most developers experience this –- as did I. Business Analysis begins to look inviting, in particular because of the next point. • Business Analysis is less technically taxing than programming: I expect this to raise hackles, but I have done both and the simple truth is that it is not as technically difficult to write a user story or use case as it is to write the code that implements it. There is still novelty, complexity and creativity – but you find it more in the new business areas you are exposed to rather than in technical challenges. • natural evolution: As you work your way up a career on the IT side, you naturally evolve towards a focus on higher levels of abstraction that move you further from the technical perspective and closer towards the business. The next logical step is Business Analysis – the function that bridges those two worlds. • Desire to be in a new/growing profession: When I entered the profession, there were few BAs out there, no BA organization, and no formally recognized role. Like many people in IT development, I was naturally drawn towards areas that were new, where there was a green field to be innovative – and Business Analysis fit the bill. While that is not as much the case now as it was then, the field is still young and growing – and even still in its infancy in many countries. • the financial motivator (i.e., money): As you get closer to the side that generates wealth, your pay rate rises accordingly. Generally speaking, ‘business’ BAs make more than ‘IT’ BAs, who make more than technical analysts and programmers. The argument is particularly compelling if you are a programmer working offshore, and the BA jobs you are seeking are located in North America or Europe. (See Job Security below.) • Job Security: Programming is increasingly being seen as a commodity service that can be outsourced to the lowest bidder – thanks, in part, to globalization, and to the easy ability through the Internet to source programming resources from across the globe. Business Analysis, on the other hand, requires close contact between the BA and business stakeholders; this typically means that the BA function must be performed locally, and that it will probably remain resistant to off-shoring for the foreseeable future. (The fear of having your job outsourced is not exclusive to North America and Europe, by the way; I’ve heard developers in India express the same fears. There always seems to be a cheaper source of programmers somewhere.) • Path to Emigration: I’ve met and trained many developers offshore, whose prime motivation was the opportunity the BA profession provided to work onshore. And it’s worked out well for many of those I’ve met who have made the move. The reasons vary not only by the individual person but by where they sit within the organization. For example, when I speak with the CEOs and VPs of IT service and development companies, about developing a BA competency using their existing programmers, the prime motivator I hear is the opportunity it provides to increase revenue from their existing client base by broadening and deepening the services they provide them. On the other hand, I hear a different motivation when speaking with the VPs of IT departments within large organizations: Their expressed goal is to better serve their business customers by doing a better job of going from a business problem to an IT solution. WHAt ArE tHE CHALLEnGES? Here comes the bad news for anyone considering the transition. A great programmer does not necessarily make a great BA. To be excellent at business analysis, you need a package of personality traits that don’t often come together in a single individual: a strong analytical side, coupled with highly advanced interpersonal skills. If you don’t have those ‘soft skills’, no amount of training in business analysis tools will make you a great BA. (The good news, though, is that there are things you can do to develop those areas of your personality that are currently weak, as I’ll describe at the end of this article.) So before you set out to become a BA, ask yourself these questions: 5 quEStIonS you SHouLD ASk yourSELf, BEforE you StArt trAnSItIonInG froM It DEvELoPMEnt Into BuSInESS AnALySIS 1. Do I have a sincere interest in business (or, can I at least put myself in the shoes of someone who does)? The transition from IT developer to Business Analyst requires a change in mindset. To be an effective BA, you either have to genuinely care about business issues, or be able to put yourself in the heads of someone who does. It can be a challenge for someone who originally got into IT because of a passion for the abstract logic of programming. Some programmers are 21
Page 1 and 2: ord onfirmation rdering ord We love
Page 3 and 4: 4 By Jøran Lillesand and Eirik Lie
Page 5 and 6: 8 SCroLLInG BotH WAyS Winrt for the
Page 7 and 8: ASynCHronouS ProGrAMMInG WItH ASynC
Page 9: In my work in non-governmental orga
Page 13 and 14: NDC is one of the World’s largest
Page 15 and 16: 28 BEInG A DrIvEn ProDuCt oWnEr I r
Page 17 and 18: I can’t really speak about the qu
Page 19 and 20: 36 Ember.js positions itself as a f
Page 21 and 22: DESCrIPtIon During the ScrumMaster
Page 23 and 24: Scrum Arne Laugstøl Mike Cohn Geof
Page 25 and 26: DeSign - analySiS- architectureS Cr
Page 27 and 28: microSoft continued Arne Laugstøl
Page 29 and 30: courSe overvieW oSlo courSetitle ag

We love SMS!

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?