Tagged “Architect”
-
Refactoring Azure DevOps
I've been spending time this week, refactoring our Azure DevOps tenant. We have been using Azure DevOps at my company for as long as I can remember (well over 10 years?), and over time we've used it in different ways. We never had good governance, but would create projects and teams within projects as they come up.
For the past several years, we've had one main project in Azure DevOps where we would create a team within the project for each of our actual projects. This allowed us to roll-up all our tasks to the main board, but resulted in us being locked into a single process type, iterations, and more.
We would also have separate projects created for each repository we needed.
I'm working on breaking away from the consolidated team and using DevOps how I think it was intended. One project per client. Within that project, we'll have teams for each major initiative (most projects only have one). All the repositories for that client are within that same project.
This approach allows us to more easily manage team members, permissions, and each project can have its process. In other words, our simple projects can have a simple To Do, Doing, Done type approach, while our bigger projects can have additional states that give us more control.
The separate projects will make it easier to have a single Wiki per client, as well as dashboards, control over sprints (when we use them), and much more.
Overall, it's pretty easy to move tasks around. Create a query, select the tasks I want to move, right-click and move to project. But it does get tedious. I'm excited for it being done. Maybe a weekend project?
-
The unfortunate side affect of being a senior architect
I spent my early career developing websites, and later business applications. I'd spend all day, nearly every day coding, and I loved it.
Although, never considered myself to be a good developer. The part I was good at was the design of the application. My code was organized, reusable, consistent, and worked well. I was good at deciding what needed to be built, and how.
Eventually, I became a senior developer, and eventually an architect.
The unfortunate side effect of being an architect, is I can no longer write code all day long.
I have many other responsibilities. In fact, writing code is a necessary luxury. I have to do it to keep up to date, but my real job is to provide estimates, documentation, code reviews, and direction to other developers. And the meetings, oh I love the meetings (not!).
"If a company’s most senior engineers just write code all day, the codebase will see the benefit of their skills, but the company will miss out on the things that only they can do. This kind of technical leadership needs to be part of the job description of the person doing it. It isn’t a distraction from the job: it is the job." (Tanya Reilly, The Staff Engineer's Path)
It's all good. I still love my job.
-
How writing can help you solve problems
Have you ever started an email to someone that explains a problem to them, one that you don’t know the solution to, then by the time you finish the email, you’ve realized you have come up with a solution?
Simply writing out a problem where the explanation is as simple as possible (so someone else can understand it), we are clarifying in our mind precisely what the problem is. You likely don’t understand if you can’t explain the situation to someone else.
Understanding the problem is only the first part. Now we try to come up with a solution. Often there are multiple solutions. So, we start listing some potential solutions and thinking through the pros and cons of each solution.
As we write out the potential options to solve the problem, we often eliminate specific options based on what we know about the situation. Perhaps it is a budget issue or an infrastructure limitation. The more we can get down on paper (digital or analog) more likely we are to come up with the best options.
As a Software Architect, this happens to me all the time. So much that I’ve incorporated this into my workflow. When I need to deal with a problem, even if I think I understand the problem, I write it out in the most straightforward explanation possible. Then each option will have pros and cons, and I’ll usually have a recommendation of which option I think would work best or is most reasonable within the current circumstances.
After going through this process, I’ve often solved the problem and realized the best solution we can implement immediately. Clients love being told there was a problem and that you already took care of it. There is also the added benefit of having everything documented.
I’ll write on paper when I’m struggling with something I can’t wrap my head around. This slows me down, so I can spend time thinking as I go. When writing on a computer, it’s easy to spit out words that don’t have as much meaning. On the flip side, a computer makes it easier to delete and reorganize ideas.
Writing out our problems is not only for technical issues; it can work for anything. This is why Journaling is so beneficial.
Writing is thinking.
-
Document your work
Please document your work! I’m speaking from the context of a software developer/architect, but this also applies elsewhere.
At the moment, it may feel like a waste of time. You may think, “I’ll remember this.” or “I’ll never do this again.” I’ve been there (and still think this). However, documenting has so many advantages. I’m pushing myself to do better at it constantly. More documentation with less effort.
Creating documentation is a great way to go through whatever it is in greater detail and ensure you don’t miss anything. I can’t count how many times I thought I was finished with a task, but then found something I missed while writing out what I did.
Writing, in general, helps to ensure you understand a topic. If you can’t write about it, perhaps you don’t understand it as thoroughly as you thought you did.
Referring to a document to complete a task can dramatically speed up the execution time and improve quality. You spend a little more time upfront to save time in the future.
One of my favorite reasons to document my work is so that I can give it to others to do next time. I can send them the documentation and allow them to complete the task independently. Better still, when your team has access to all your documentation, they’ll learn they don’t need to come to you in the first place!
It’s a wonderful feeling when someone asks you a question, and rather than taking time to answer it now, you can send them a link to the documentation. It may be an official Word Document, a OneNote page, or even a blog post. If you don’t have the answer documented by someone, add the answer to the documentation now! I don’t know how many times I’ve answered the same question multiple times when I could have documented it. (I’m trying to be better about this.)
My “work” documentation is either in OneNote or other Office documents. I’m doing this because these destinations are shared with my team and easily discovered in the Microsoft 365 universe. My personal documentation resides in markdown files tucked neatly inside my favorite note's app; some are published as blog posts.
Where do you keep your documentation, and how detailed do you get with it?
See all tags.