I’m suggesting that most companies have a core infrastructure that is fundamentally predictive-convergent. Using adaptive-emergent techniques, language, methodology and tools is fundamentally destined to fail in predictive-converegent companies. It’s not that agile can’t be adapted or scaled to work in these predictive-converegent companies, it’s just that it requires a different language and approach.
Organizations increasingly face the challenge of how to strengthen employee engagement while their workforce increasingly work from remote locations or while mobile. There is a great opportunity for internal communications to take a leading role with developing a plan that addresses these challenges with greater use of communications channels.
In full disclosure, I'm writing this as a "Chief" Architect (I can't help but picture a big headdress), and I've spent the majority of my career as an "architect" (note the air quotes).
By 2022 it will be not be possible to get a professional programming job if you do not practice TDD routinely.
Every week here and in our newsletter, we feature a new developer/blogger from the DZone community to catch up and find out what he or she is working on now and what's coming next. This week we're talking to Ralf Quebbemann, Java developer with a special focus on Maven, and a dedicated Blues guitarist. Some of his most recent DZone contributions include:
Starting with the control/data plane concept, I broke apart the cloud into multiple planes and then focused on how the layers would communicate to enable a cloud management platform that inherently scaled in and out as well as up and down.
Now that the team is armed with new weapons, it is time to help the Scrum Master to fight back. If you didn’t read my first post on this topic have a look at the 10 things a Scrum Master can do to drive the team crazy blog post I wrote two years ago. Here we go:
In a previous post I wrote of why I like to participate in hackathons. This time I'd like to talk about how to participate. What sort of prep work you will need to to get ready.
This is intended as a bare-bones intro to saving for retirement, targeted at software engineers. Ballpark, you make about $100k a year in your 20s. If you want to have that same income in retirement, you need about four million dollars saved up.
We Agile practitioners are probably less thrilled by these New Year’s traditions. We have been desensitized by countless iterations kicking off with commitments and coming to a close with retrospectives. Our cynicism toward a Waterfall approach most likely makes most of us jaded about these end-of-the-year festivities. Or maybe not?
Managing energy is more important than managing time. Energy is what gets things done, and time is only a crude surrogate for energy. Instead of only looking at what you could earn per hour versus what you could hire someone else for per hour, consider the energy it would take you to do something versus the energy it would free to delegate it.
I love the Mac computing experience. Even though I use a Mac as my home laptop, I prefer a Linux machine for work. Here are the key differences between developing on a Mac and on Linux.
Software is more about people than technology. When I graduated from college, I thought I only had to master technical skills to be a great developer, thinking that people skills are the appanage of managers solely.
All code can be classified into two distinct roles; code that does work (algorithms) and code that coordinates work (coordinators). I would say that 90% of the code I have written does not nicely divide my classes into algorithms and coordinators.
I had a boss who was great at saying, “Terri did this. Jen did that. JR did this other thing.” We all knew who had learned about different areas of the system, who had succeeded at which parts of testing or development or project management. It was great. Contrast that with some other places I’ve worked...
In software development, building a great team is a delicate yet achievable goal. Although there isn't an exact formula, most managers would come to a common consensus on the basics. The formula might look something like this: Varying Skill Sets + Seasoned Members + Balanced Personalities + Proper Mindset = Success!
This is the Big 4. The architectures, that may help your work. They may influence the way you think about programming.
Suddenly, there’s an avalanche of company holidays and vacation time that throws off your velocity and cadence. Here are 3 ways you can make the end of the year a useful and productive time rather than a few weeks of frustration and waste.
Agile practices as described in the literature are suitable for small co-located teams focused on a single product. These small co-located teams quickly and efficiently establish a shared understanding of a project, the customer, and the architecture they are working within.
It’s been a long time since I wrote “10 things to drive your Scrum Master crazy” and it’s about time to give you some new weapons. So, here they are:
It’s been a funny transition the past few years as agile has gone more and more mainstream. You used to have to start every talk with an explanation of the Agile Manifesto… you don’t have to do that anymore, people generally get it.
You hear a lot about “change the ratio” and encouraging young people, especially young women, into technology. Njeri “Martha” Chuomo is 19 years old, a Ruby programmer living in Nairobi, and changing more than just the ratio.
There are many ways to learn but teaching might be the best one.
Let me ask you a question; why do agile frameworks recommend limiting team size to 7±2? If you answered “communication” or "collaboration", congratulations you're correct. But do you understand why?
The topic of perfection is a common discussion at the programming dinner table. Is it good? Is it bad? Is it healthy? Is it possible? Is it realistic? With that in mind, the following section outlines the benefits and pitfalls of perfectionism in software development: