What part of development should a software designer do? [closed]

Question

My manager recently promoted me to "software designer". I am not aware that this title exists. As far as I know SAs creates high level code design and do diagrams.

I have a hard time understanding what high level code design I should do. According to my manager, I should design all classes and all methods inside those classes. That is, I would design the whole code structure, and let my team implement the functionality of each function or class. For example, in a CRUD system I should be able to plan what function should be use or what classes to be created.

Given my software design experience, I found this extremely imposible to do. As a developer, I always create my own classes, define and implement my own functions. I've never experienced designing functions for others.

My questions are:

• Is this common? For a very large system, doesn't the code base change all the time?
• Can this be done?

I realize I might be asking an obvious and stupid question here, but I have always been a regular developer until now and so havve no experience in designing whole systems.

Answer 1

Preliminary notes about titles:

• Sometimes, what you really do doesn't match at all your official title. As an example, years ago, I was hired as an “analyst-programmer in R&D department”; however, nobody hire did analysis, nor programming, nor research, nor development. What I (and others) actually did was coding. A monkey could do half of the stuff I did. Any undergrad intern could do the other half.

• Often, the title doesn't matter. In some companies, you may end up doing a lot of different and diverse tasks, and there is simply no title which describes all that. In one company, I did the tasks of an architect, a team lead, a manager, an UX guy, a coder and a productivity specialist, and I was ensuring two teams were communicating correctly with each other. There is no single title for that.

• Finally, titles may have different meanings in different companies, or people who give titles in the first place have no slightest idea about the real meaning of the title, if there is any. In some cases, there are just fashionable titles and buzzwords. You don't need a system administrator—that's old fashioned. You need a DevOps specialist. You don't talk about business intelligence or data mining when you try to hire someone: you talk about Big Data!

So forget about titles, and focus on what exactly you were asked to do. Luckily, your question does exactly that.

Is this common? For a very large system, doesn't the code base change all the time?

I haven't seen it, and I don't believe it could be sustainable.

Can this be done?

Yes, but at a cost of normal people leaving the team.

What your manager may have in mind is that you do the design and present it in a form of UML diagrams. It's old fashioned, but who cares? The practice was quite popular in some companies, and still works decently well in others. It may be a suitable approach if you're very skillful, but all other members of your team are beginner programmers: they simply don't have enough experience to do the proper design themselves, and you're in a very good position to help them.

If I were you, I would start by talking with your manager, in order to determine whether it's really this that he has in mind. If yes, play the game, and try this approach for a week or two. What could possibly happen?

Either you'll discover that the approach works well for your team, in which case, thank your manager for his insight, or the approach won't work.

In this case, talk with your team first, in order to identify all together why didn't it work, and what should be done to improve the process (in other words, do a retrospective). Then, either implement the changes to the process if you're in a position to do it, or go visit your manager and discuss it with him.

Then repeat. Every two weeks (or what seems appropriate in your context).

Answer 2

Ideally, Software Architect is another term for Senior Software Engineer, maybe with some additional responsibilities, or as a way of providing some general recognition of that person that they are the official point-of-contact on technical issues with the systems they work with, or that less-familiar members of the development team can rely upon them when they don't know why some part of the system has been designed in a particular way. or are struggling with an issue when they can't find a good/acceptable solution to a problem.

In my opinion, a Software Architect should not be someone who works in a proverbial 'ivory tower' creating designs or making unilateral decisions for other developers; design decisions must still be driven by the people who are actively involved in writing and maintaining the code, and development teams must have collective responsibility, with individual developers being responsible for the quality of their own code, for understanding the design of a system, and for not introducing any changes which "break" the architecture or which introduce unacceptable levels of technical debt.

While it can sometimes be valuable to capture the high-level design of a system as a means of helping a software team communicate ideas and share knowledge (particularly to newcomers and inexperienced developers), the main activity of design is that of writing the code itself (including automated tests); It would make sense for a Software Architect to take 'ownership' of design documentation, although that's not the same thing as saying they're the ones writing it; more that they ensure the team creates necessary and sufficient documentation, and is available to review it for accuracy.

For all practical purposes, there's little or no value to be had in attempting to separate the role of software design away from development because they are essentially the same thing - indeed the reality is usually rather harmful because it tends to lead to a mentality whereby developers are treated as production-line "code monkeys" forbidden from thinking for themselves.

Answer 3

By your description, it seems that your manager wants you to assume a leadership position and do not know how to articulate this

He promoted you and want you to design the software and split the tasks. His confusion on how to articulate is natural. He is puting you in a leadership position that can be easly confused with his role as manager.

Traditional developement teams have a single manager which is divided between external activities (seek funding, politics, head hunting talents, sell the ideas and products and etc) and internal activities (coordinate the development). But this activities are in conflict and requires different skills sets. Usually "the manager" is good in the external activities and bad on the internal.

This roles can be separated. Actually is one of the key characteristics of the Scrum Methodology. The successfull and productive teams I know did separated those roles. And most does not even know they are doing that: one of the programers started to organize the team and the manager let it.

This only works if there is a bond of trust between "the manager" and the "lead developer". Many teams fail. As the one of the developers take leadership, the manager can feel threatened or jealous. The team may loose respect of the manager because he or she is out all the time and they do not understand how important the external activities are. It is important to be aware of that and avoid those problems.

How to divide the tasks

In order to divide the tasks you do not need to follow his example.

It is important to abuse of proof of concepts, functional exploratory prototypes to make the progress of the team more visible to him. The important thing is that he feel that the development is progressing.

One way to achieve that is to make a sql-only prototype. Create tables, populate with data, create sql-only test cases that execute the queries that main screens and routines would do. When you are confident that the simulation are good, split the work between your junior developers to build the screens and routines. While your junior developers are working, you are making the prototypes for the next developement cycle.

Everybody is busy, productivity is high, the manager is happy.

Answer 4

Try it for a couple of sprints but you will seriously annoy the developers you’re managing and they’ll in turn moan to whoever’s listening.

I’d go with the assumption that you’re setting the general architecture decisions (push vs pull; message patterns; should service x be DDD or is CRUD fine)for the team; then using the code review process and pairing to keep everyone on track and help them out if they’re getting stuck.

It really doesn’t have to be top down, death by UML. What you’re looking out for are classes in the wrong place; business logic not being where you’d expect it and so on.

Don’t be too hard on the team if they’re learning something knew, work on any new principles first then clean up any lingering bad practices.