Today I sat with Moran after he “paged” me. He reviewed some code of one of our applications and he saw some things he thought he could make better. It was one of those classic “Hey! it should be a single service which every one of our applications will use!”. Step after step he made the required refactoring and some elegant API took shape. The improvement was in magnitude but I still thought that the API should be quite different before making it “public” and placing it in our infrastructure. But, and that’s a big but, the guys that develop the specific application needed the class and Moran was required to help in another project.
Should Moran take the opportunity to invest some time in this API? Should I help him through? We can talk about services, about providers, about extendability. We can play with code just to see how the API will look like. We can play with ideas, learn from each other, share our experience. We can share with others, we can send some quick “API tests” to get some feedbacks.
The process of developing the basics for our applications should be *long*. It should allow space for errors. The margins should be wide enough to let us experience, to learn from our mistakes, to discuss, to make Design Reviews, To Prototyping and throwing it all to the garbage 2 days later. It’s all OK.
But maybe this is not the right time for games. Maybe Moran should make it work somehow and carry on to the next project ? After all, the next project’s deadline is near(like always) and we need to join forces just to keep it up. Hey! we get paid to reach deadlines, to make it happen while keeping the quality at high level. The deadline is sacred. I truly believe that a good team will deliver on time even on the expense of features or well-known but low prioritized bugs.
On the one hand, I know that developing small to medium applications (0.5-2 human years) almost never allow you to invest the required amount of time in the basics. On the other hand, I also know that developing applications at work and infrastructures at home is not the answer for long terms. The process is short. No errors are allowed. There is almost no Design Reviews. Does it mean that the results of “home infrastructures” will be poor ? of course not, but the experience, the ability to break our requirements to programmer stories, to exchange ideas, to grow – is lost. The funniest part is that developing small application without a solid infrastructure turns into medium-large application. I guess it’s the egg-chicken paradox.
The best I can do is to tell the reality from my perspective. My reality is that there is never time(well, that depends on
the urgency and the magnitude of the application), and keeping with my expectations makes me perform the global thinking and implementation at home. This is the only time that I actually “have the time”. Investing my time in developing some required infrastructure can save my guys at work a significant amount of work. Still, putting the effort on developing infrastructure during work hours will come on the expense of developing user stories, mentoring, guiding, consulting, talking with our customers. I guess that I still don’t know my place. I’m a good developer, I would like to think, and coding some really interesting delegates-based infrastructure or some neat OOP solution are those treats I can’t live without. Still, leading projects, make sure everything ticks and the quality is high is a challenge I love to face in my every-day work; Above all – seeing my guys getting to the next step and helping them in this journey is the main reason I’m doing what I’m doing. I want to be the best I can be for my team and yet make an influence in the way we work via developing some solid infrastructures. My gut feeling is that I need to get better. I feel that I can and should be a lot better as a manager and a programmer but It is still very hard for me to decide how and where to invest my time.
This issue keeps me awake at nights “lately”(last 6 months or so).
Where do you put the line ? How do you decide to invest your time in programming on the expense of managing and vice versa ? When do you think it’ss appropriate to invest additional hour\day\month to something you believe in ? Do you have some rules of thumb ?
4 thoughts on “So when is it a good time to develop infrastructures ?!”
I really believe the answer to your problem lies in iterative approaches and constant refactoring. You are dividing your team’s work to either "infrastructure/API" or "make it work somehow" – the solutions lies somewhere in the middle. Seperating these two concepts so strongly may also lead you to the notion that "infrastructure/API" is for expert programmers while "make it work somehow" is the job of average ones. If you can find a way for infrastructure to be intertwined with day-to-day work so that duplications can be avoided and design improved but extensability is limited to actual requirements, you may find it is less time consuming and usually pays off earlier than expected. Designing an over-abstracted over-extensible API is just as bad as spaghetti coding, unless you’re in the business of selling API’s…
Maybe you should focus your time on mentoring. Designing cool API’s is a lot of fun but making other people do it for you is a lot more effective.
As a team leader, I experienced the same kind of dillemmas. In my opinion, leading a software development team is one of the most difficult tasks in the whole software development range of duties. Towards management, you are responsible to deliver reliable software, in time and as Yoni called it "make it work". Usually you are simultaneously responsible for at least 2 versions – supporting already deployed versions and developing the next version. Towards your team members you are responsible to provide them with explicit tasks, allow them the time to do they work properly, keep the design appropriate for future development, remain up-to-date in terms of technologies, etc.
A very important issue is that of "critical path" – as a key person in the development process, you should NEVER be directly responsible for tasks that are on the critical path (i.e. tasks that are indispensible for the progress of the development). You always have meetings to attend, recruitements to do, people to mentor, so you inevitably run into cases where you can’t complete all of your tasks. In most cases, it’s the development tasks you’ll have to give up. If it’s a task that is critical – you’re (dead)locking the whole development process.
I found it very frustrating not being able to have enough time to actually write code, as a team leader. It differs from team to team, person to person and of course company to company, but in general, you need to take upon yourself development tasks that are not critical, short in time, fun to do and add "cool" functionality to the system. This will force you to find time for them. Also, when you’re doing that, you can better focus on the overal design, mentoring and other management tasks. Roughly speaking, I think that a manager of a 4+ persons team (manager not included) will be left with very little actual coding time (less than 20%).
As for the infrastructure vs. make-it-work, when as a team leader you focus your mind more on management and professional coaching than on actual coding, you will find yourself looking at things from a different perspective (i.e. from "higher up"), and it will be easier to decide on a case-by-case basis. In most cases you will try to solve the urgent issues in one of two ways: quick-and-dirty-throw-away-before-the-next-version or, in a reasonably good manner that will serve as good ground for improvement in the next release. In both cases, however, it is very important to write down (and update management!!) that in the next release you will need to have enough time to do the required changes. This becomes an issue of politics and negotiation. However, once you and your manager (and sometimes sales/marketing become involved as well) get accustomed to this, it works pretty well.
Like everything in life, these decisions are never black or white, and you end up choosing the level of gray that is the most appropriate for the current situation.
This is all, of course, from my own experience, and I guess everyone may see in many different ways.
first, you have been influence at least on one person that i know – it is me! i’m oweing you a lot to where i’m standing today
second, i think the situation you mentioned is happend in many fields of life.
i found my self a lot of the times in the last month, thinking how to split my time between work and studies.
i found that the best soultion for me is to split it to periods.
some period i spend most of time studing and some period i spend most of the time at work.
so in your situation and as you said, developing infrastructure is importent and furthermore you learning a lot from it, but some times you need to spend the time leading some project, reviewing code and you do not have the time to do the things you wish too.
So, as i see it, relax at home, read book, enjoy with your family, these things will not be the same tommorow, Ms train will come again and again and you will have more chances, and i’m sure some day you will think that developing it part of life, and maybe some day we will meet at india selling ice cream in the beach :)
Wow, great advices guys.
I agree with you. I remember our talk a few months ago and I couldn’t agree with you then. If I remember correctly my reason was "Well, it will take too much time and "better" people to pull it of". To be honest I still think that you need some level of programmers to make it work with effiency. But I agree that we need to work in an evniornment that will promote OOP and better thinking .vs. automating our work completly. I still didn’t figure out the balance though as I don’t have the time to sit with each programmer in our department and at current time, their quality of pure OOP will not be suffcient. I’ll figure it out somehow…
Great response, thanks. I must say that agree with everything you’ve said. I’m just feeling that it’s too early for me to move out of code into mentoring-only mode. I simply love coding. I never put my programming tasks in the critical path as I’ve learned that programmers shouldn’t wait for, well, anything. This is a lesson I learned from Pavel, my ex team leader. Maybe this is a sign that I need to be in a place where I could work more as a programmer and let someone else take all the project-management stuff from me. Maybe it’s a sign that I simply need to take this it easy, I’m still young and I sometimes want to achieve more than I think I can.
I’m glad that I managed to do some things right. working in periods is a good advice but to be honest, I’m not that kind of people. I like doing many things at the same time, it makes me smile. But you right, I don’t have the time to do everything and I really should be a little more relaxed.
I guess that in time my goals will finally meet with my abilities and time-limits and I’ll find myself in the field I love best (hardcore programmer or simply 80-20 management-coder). I wonder how lecturing and cosulting will fit in the little time I’ve got.
Comments are closed.