4 essential skills software architects need to have but often don’t - O'Reilly Media

4 essential skills software architects need to have but often don’t - O'Reilly Media: "Microservices. Continuous delivery. Reactive systems. Cloud native architecture. Many software architects (or even aspiring ones) have at least a passing familiarity with the latest trends and developments shaping their industry. There are plenty of resources available for learning these topics, everything from books and online videos to conference presentations; the ability to go from novice to expert in these areas is right at their fingertips. However, as today’s trends quickly bleed into tomorrow’s standards for development, it’s paramount that software architects become change agents within their organizations by putting into practice the “unspoken” side of their skill set: communication and people skills"



'via Blog this'

“My Code is Self-Documenting” — Eric Holscher - Surfing in Kansas

“My Code is Self-Documenting” — Eric Holscher - Surfing in Kansas: "Self-documenting code is one of the biggest documentation myths in the software industry. This view generally conflates documentation with code comments. I’d like to make two arguments in this post:

Code comments have value
Documentation has more value than just explaining how software works"



'via Blog this'

infoQ: Architecture: Technologies for the Future of Software Engineering

Technologies for the Future of Software Engineering: "The Cloud, infrastructure as code, federated architectures with APIs and anti-fragile systems: these are technologies for developing software systems that are rapidly coming into focus, claimed Mary Poppendieck. She spoke about the future of software engineering at GOTO Berlin 2016.

If you have too much data to fit on one computer, you have two options: scale up or scale out. Scaling up by using a bigger computer is usually not the right direction to take, argued Poppendieck. You need to scale out by getting more computers and build systems of computers.

Poppendieck mentioned different ways to scale out:

Scale out files: an example is the approach that Google uses for searching. Files are split up into small pieces which are copied to multiple servers. Then the searching is done in parallel, and the results from all servers are combined into one search result.
Scale out architecture: Amazon does this by breaking transactions into services and using specific servers to do the services. If there’s a bottleneck, then you can replicate the service on multiple servers. Each service is owned by a semi-autonomous "two pizza" team.
Systems are moving more and more towards the cloud; there is a cloud in your future, said Poppendieck"

Having one central database creates a dependency problem as all applications depend on the database, and changing the database can impact many applications. Poppendieck stated that "the enterprise database is a massive dependency generator". Individual teams cannot deploy autonomously as their work has to be coordinated with all other teams sharing the database. Instead of having one database, you need a federated architecture where you split into local data stores appropriate to the needs of individual modules or services, and accessed only through APIs. APIs are replacing central shared databases and they enable the internet of things. You have to learn to do software engineering with APIs, argued Poppendieck. Look at APIs as products which are owned by a responsible team, and focus on the API customers to evolve and develop new capabilities.

We need to stop trying to make systems failure free and start thinking differently, said Poppendieck. Many of our current systems are fragile; they started as robust systems but over time they have become difficult to maintain. Systems nowadays need to be anti-fragile, and able to embrace failure, claimed Poppendieck. When things go wrong, systems should be capable of limiting damage and recovering from failures.

You get anti-fragile systems from the way you test systems, which is by failure injection to make something go wrong. Poppendieck mentioned that your systems need to isolate and automatically recover from failure, in order to achieve today’s expected levels of availability and robustness.

Poppendieck mentioned aspects that are essential nowadays for developing software. She said that you need a deployment pipeline to be able to do continuous delivery, and you need cross-functional teams including product management, testers, and operations to get the benefits promised by continuous delivery. The deployment pipeline depends on automated processes for testing, migration, and deployment. Continuous delivery requires all teams to communicate through the codebase by doing continuous integration to the trunk. Teams keep the software always production-ready; if that’s not the case you have to stop and make it so. While deployment is continuous, release is incremental by toggle or switch whenever a useful increment or capability is ready.

'via Blog this'

softwareyoga.: How to be invaluable employee?

How to be invaluable employee?

Or in other words how to bring more value to the company as a result of your work?

You got to show them how your work is making a difference to their world – A world where $, savings and time to market has precedence over exceptions, design patterns and interfaces.

Listed below are some aspects that will definitely get you recognized as a programmer who goes the extra mile beyond and above the official duties.

1. Understand what the end users want in the software. Talk to them. Figure out the things they don’t like in the existing system, things they would like to improve etc. You have to solve their problems using your technical skills.
2. Identify what modules or components have the most defects in your system. Come up with high level technical approach to solve the issues. Present the ideas to the management, explain what benefits it would bring to the company and how it can save time and cost. Use statistical figures to explain how your ideas will bring vast improvements.
3. Identify things that are being done manually or with complex workarounds. Eliminate them or handle them in a better way.
4. Speak to management on what they think are the biggest problem areas. A lot of the times, getting input from someone who is away from the technical stuff helps immensely.
5. Evaluate new technologies for your product and present to the team and management on what benefits they may bring.
6. Identify and improve workplace processes. You will surely have few issues regarding the way some things are done in the company. Figure a way to alleviate the issues.
7. Many a times, the project managers might over-promise or set extremely tight deadlines – not because they like sucking the last drop of blood out of you, but often because they don’t understand enough technically. Have a discussion with them on their expectations. With your technical knowledge, provide them inputs on whats possible realistically and how the scope can be altered so that everyone is a winner.
8. Draw comparisons of your work with other industries and bring in the best practices. Often, you can draw inspiration from the most unexpected places.
9. Mentor junior employees. Train other employees on various topics and practices. In most companies, you will have someone in the company who you aspire to be like some day. Meet them and ask them if they could be your mentor or if you could shadow them in their work.
10. Automate stuff outside of your product – Find people within your company who are not as tech savvy as you are. There will be some one out there who needs a helping hand. Solve people’s problems.

In conclusion, I believe that a programmer should get involved in other activities in a company, not just coding. It serves two purposes – provide you insights from a non-technical viewpoint and an understanding that programming is not the center of the universe.

Processes > People

pic.twitter.com/oQ4doPmWNP

— Jessica DeVita (@UberGeekGirl) April 30, 2016

Agile is Dead – Again

Agile is Dead – Again: "Miko identifies Continuous Delivery as the successor to agile in the market.



 The paradigm of “Continuous Delivery (CD)” seems to be the logical successor to Agile. Continuous Delivery provides an umbrella term that does not specify methodology–and doesn’t require much of a manifesto. Everything you need to know is in the title–you just deliver shippable software in as continuous of a way as possible. This allows a team to pull whichever Agile principles and methods needed in order to achieve that goal. This addresses one of the complaints of Agile, which is that it became a religious movement with gurus–and that these highly paid Agile gurus would come with one-size-fits-all solutions for development teams which were hard to realistically fit to real-world development."



'via Blog this'

Managing Technical Debt Using Total Cost of Ownership

Managing Technical Debt Using Total Cost of Ownership: "Total Cost of Ownership (TCO) can be used for investment decisions and financial benefit analysis. When applied to software it covers the initial development costs and subsequent maintenance costs until phase out of a product. TCO can support architectural decisions and management of technical debt.

Hans Sassenburg talked about total cost of ownership analysis at the Bits&Chips Software Engineering conference. In his talk Sassenburg showed several metaphors that can be used to "sell" the concept of TCO. The metaphor of technical dept is easy to understand, but people often find it difficult to see technical debt increasing during the product lifecycle and take action said Sassenburg.

InfoQ did an interview with Sassenburg about using the total cost of ownership concept for managing software development, the main causes of technical debt and how to reduce technical debt or prevent accumulation of debt, managing R&D investments and costs and improving the quality of software products."



'via Blog this'

Simple Sketches for Diagramming Your Software Architecture | Voxxed

Simple Sketches for Diagramming Your Software Architecture | Voxxed: "Informal boxes and lines sketches can work very well, but there are many pitfalls associated with communicating software designs in this way. My approach is to use a small collection of simple diagrams that each show a different part of the same overall story. In order to do this though, you need to agree on a simple way to think about the software system that you’re building.

Assuming an object oriented programming language, the way that I like to think about a software system is as follows: a software system is made up of a number of containers, which themselves are made up of a number of components, which in turn are implemented by one or more classes. It’s a simple hierarchy of logical technical building blocks that can be used to illustrate the static structure of most of the software systems I’ve ever encountered. With this set of abstractions in mind, you can then draw diagrams at each level in turn. I call this my C4 model: context, containers, components and classes. Some diagrams will help to explain this further."



'via Blog this'

Software Architecture links

Ben Morris: What role do architects have in agile development?

Enter the “master developer”

In this case, some kind of design authority is generally required to work across the teams to ensure the integrity of the overall system and spot issues before they become obstacles. This role shouldn’t be confused with governance, where design edicts are sent down to teams from the “ivory towers” and architecture boards. It can only be effective with the consent of the teams.

General Software Development process links

Microsoft Research: Exploding Software-Engineering Myths

The logical assumption would be that more code coverage results in higher-quality code. But what Nagappan and his colleagues saw was that, contrary to what is taught in academia, higher code coverage was not the best measure of post-release failures in the field. Code coverage is not indicative of usage.

What the research team found was that the TDD teams produced code that was 60 to 90 percent better in terms of defect density than non-TDD teams. They also discovered that TDD teams took longer to complete their projects—15 to 35 percent longer.

The team observed a definite negative correlation: more assertions and code verifications means fewer bugs. Looking behind the straight statistical evidence, they also found a contextual variable: experience. Software engineers who were able to make productive use of assertions in their code base tended to be well-trained and experienced, a factor that contributed to the end results. These factors built an empirical body of knowledge that proved the utility of assertions.

Adam Thornhill : Code as a Crime Scene

Code as a Crime Scene

To understand large-scale software systems we need to look at their evolution. The history of our system provides us with data we cannot derive from a single snapshot of the source code. Instead Versions Control System (VCS) data blends technical, social and organizational information along a temporal axis that let us map out our interaction patterns in the code. Analyzing these patterns gives us early warnings on potential design issues and development bottlenecks, as well as suggesting new modularities based on actual interactions with the code. Addressing these issues saves costs, simplifies maintenance and let us evolve our systems in the direction of how we actually work with the code.

The road ahead points to a wider application of the techniques. While this article focused on analyzing the design aspect of software, reading code is a harder problem to solve. Integrating analysis of VCS data in the daily workflow of the programmer would allow such a system to provide reading recommendations. For example, “programmers that read the code for the Communication module also checked-out the UserStatistics module” is a likely future recommendation to be seen in your favorite IDE.

Integrating VCS data into our daily workflow would allow future analysis methods to be more fine-grained. There's much improvement to be made if we could consider the time-scale within a single commit. As such, VCS data serves as both feedback and a helpful guide.