About 2 months ago InfoWorld published 11 programming trends to watch. I’d like to share three with you since they are close to home for me:
- No code is an island
- Bandwidth is no longer free
- Energy is no longer free, either
No code is an island
Having worked in integration project for almost a decade the idea that there is little code living on an island is not strange to me. However InfoWorld points out that besides that more and more software developer are creating products to enhance other products
Our code is living increasingly in ecosystems. Many PHP programmers, for instance, create plug-ins for WordPress, Drupal, Joomla, or some other framework. Their code is a module that works with other modules.
The same goes for development for mobile devices that rely increasingly on modules or apps created by others, whether they run on the device or in the cloud. This increases the demand for stable interfaces and contracts. Besides that the requirements for availability and scalability will weigh in heavier.
An urge for lean programming
Or create programs that deliver value in an efficient way. New releases of software programmers tend to demand always more resources (just a small example). The cost of keeping a computer plugged in has never been an issue. It never mattered how much energy your rack of servers sucked down because the colo just sent you a flat bill for each box.
The Cloud trend tends to make cost more transparent. Some of the clouds — like Google App Engine or Amazon S3 (example) — don’t bill by the rack or root password. They charge for database commits and queries. This adds a new perspective for software developers. We might need to start thinking about the cost of each subroutine in euros, not in lines of code, function points or milliseconds of execution time.
On the consumer side more and more ISPs adding bandwidth caps and metering. To a software developer this means that optimizing bandwidth consumption when designing apps is becoming imperative. Besides the cost issue this will also be needed because of the customer experience (loading speed etc).
Since this blog is also dedicated to sharing resources that are valueable to me I decided to share my reading list of 2011 with you.
Lean Integration: An Integration Factory Approach to Business Agility
A great best practices book on integration. The first part provides description of the business value of Lean. It introduces the core concepts. As a manager that doesn’t need all the details you could just read this part and you can get a good grasp of the ideas presented.
The second part translates the lean principles from the world of manufacturing to the world of systems integration. It has great case studies that shows the principles applied in a real world context.
Part three of the book provides a “how to” guide. This can be used as a reference and as such is a great desk-top reference manual. This book is great and a must read for all technology and business practitioners and innovators.
Web Service Contract Design and Versioning for SOA
Great reference (not a book that I read front to back) on Web Service Design from Thomas Erl and his co-authors. This book focuses exclusively on the contract part of the service. Due to the depth it is a extensive resource to use besides others. The book is filled with extensive examples on how to meet the goals of SOA properly using contract design.
Via the site of the publisher and on iTunes are additional service design podcasts by the authors of the book. Could be a great resource to start with.
The Back of the Napkin (Expanded Edition): Solving Problems and Selling Ideas with Pictures
This is a great book on problem solving, extremely useful and in a sense thought provoking. It structures problem-solving into a six by five visual codex. This makes sense; you can literally see the evolution of the thought processes and the development of the insights take shape through the pages. Fun read as well.
Certificate Professional Scrum Master I
Maybe you noted that there was a growing number of post on subjects like
Scrum,
Agile and
Lean on my blog. Because of my renewed experience in this field. I decide to go for certification on the subject.
Besides the Scrum Guide and a training, you can find additional Scrum resources i like here.
As you can see in the picture in this post I succeeded.
Congratulations on passing the PSM I assessment! You have demonstrated a fundamental knowledge of the Scrum process. This qualifies you for certification as a Professional Scrum Master I.
Still wanted to share some thought and ideas with you I took from the LAC 2011 – the largest symposium in The Netherlands on architecture in the digital world. The larger part of this post is taken from the key note on Speed and Innovation through Architecture by Jan Bosch. He states:
Speed trumps any other improvement R&D can provide to the company.
Speed and time to market deliver far more value than increasing the efficiency of a process. This especially holds for non-repetitive process like (software) product creation. To increase the speed and reduce time to market we should focus on the following aspects:
- Small teams
- Architecture
- Release process
Small teams
Small teams work on the people side because a team member can experience the fruits of his or her individual efforts while on the other hand they contain the rewarding social element of camaraderie. Both are necessary for people to see their work as fulfilling.
On the process side, small teams increase speed because of the lowered need for coordination within the team and the existence of complexity. A team larger than three is required because of the need to learn from each other, the ability to deliver significant work and enable preservation of knowledge from the feedback the team has encountered. To get speed in the team at a high level the team needs to be self directed and managed.
Architecture – Keep it simple
First and foremost make sure your architecture enables you to simplify things! Keep in mind that rules and constraints can create complexity. And that is something you wanted to avoid when you started with architecture in the first place.
Architecture provides simplicity, compositionality and is designed in parallel with software development
An example would be to limit the number of things a team has to worry about during development. This could be done by applying the 3 API rule and there are other ways as well. Allways ask the questions whether the architecture enables the development team to perform.
Release process
In order to get speed into your development process you need to know/measure what people do, not what they think. Factor out opinion and chose data. To get proper results here you need a short PDCA cycle. Check and measure to get results back into your development process. This requires that you release early and often. Which in turn demands automated deployment and test.
The basics of Scrum can be found in the Scrum Guide. Besides that there are loads of resources available on the subject. In this post I’ll share a few with you I recently discussed with my colleagues:
- The Nine Boxes – Interviewing technique to help you understand problems and opportunities faced by others.
- Tools, tricks, and tips for great retrospectives can be found in the book: Agile Retrospectives: Making Good Teams Great
- The classic on The Theory of Constraints (TOC) and Optimized Production Technology (OPT): The Goal. Very interesting book on ongoing improvement written in an easy to read novel style.
Besides these the online library of one of my colleagues gives some other great hints. You might also like to read his selection of 10 from ‘Corps Business: The 30 Management Principles of the U.S. Marines’.
Recently while listening to OTN ArchBeat podcasts, a panel discussion on Reference Architectures (part 2 and part 3) I was thinking back to some pieces I wrote on industry data models and processes that I didn’t share with you yet. There a some similar argument to using these and reference architectures.
The value of reference models whether it contains data models, standardized messages, processes of a reference architecture, is or should be in a faster time to market and better quality of the solution.
Handle with care
What makes it hard to achieve this value, is the fact that these models contain always far more than is needed. That can be considered a waste. Even the parts that are not used still require attention while implementing and maintaining. This incurs work to understand the complex model, hide the details you don’t need, and customize and extend the parts you need.
Implementing a reference model requires spending time to determine how and to what extend this model meets the needs of your business? That is typically something you have to discover for yourself. It is where the majority of the time is spend! If you don’t go through the effort of understanding your business requirements, you are missing understanding of how the business can and should use the model. That makes it very hard to determine the value of the end solution to the business.
When using a reference models you should be aware that your business is not average. In some shape or form it delivers value to your customers in away a reference model doesn’t provide. Reference models should be used with care your business deserves.
Working at a customer in recent months I was on the receiving end of a Scrum coaching project. Unfortunately this ended early. And I started thinking about what I could learn from my angle as a team member. I came up with the following cases and hope they can be helpful for you as well.
Stick to your role and deliver value
If you take the role of coach in a certain expertise field, stick to the that role. This will give you focus and a higher probability of success in the field in which you perform really well. In addition to that, this is the thing/trick you are hired for. It is great if you can deliver additional value, and get the team of organization you are coaching to a higher level, only after you are delivering what you should deliver.
For example you’re coaching in SCRUM, and there is loads of work to do to get the Product Backlog in good shape, getting the documentation up to par, and help the people with the SCRUM way of working; it might not be the time to debate all kind of possible coding issues, try to remove commit hooks from SVN (requiring an JIRA issue number) and other stuff like that.
Should you as a coach decide to be a part of the team, you also have to commit to results delivered by the team (that now includes you). After you check out the code it doesn’t shown you value individuals if the only thing you do is place remarks and object without not delivering anything yourself (let alone things perceived as value by the product owner).
Stick to your role.
Focus
Focus on your assignment and the results you have to deliver. In the case you are coaching a team in the world of SCRUM it is not necessary to start a debate on all design, technical, technology and frameworks choices that are made in the first week. When valuing individuals and interactions over processes and tools, also keep in mind that it is the team of those individuals that made a range of choices. Some of them could very well be the result of much (heated) debate.
Focus on your assignment and the results you have to deliver. Don’t (re)fight every battle.
Just uploaded the presentation I gave at the Seminar “Lean & Agile IT: beter resultaat, betrokkenheid en IT volwassenheid” (Dutch) on Lean Integration. Besides the aspect of getting a lean process to create integrations we also focused on how integration is lean in the sense that it can create value.
Within lean and other practices the 5 Whys are used to determine a root cause of a defect or problem. However in the following TED talk Simon Sinek shows us that most of the times the answer to one why determines whether we as customer experience value delivered in a product or service:
