And Management Decides

There is a myth that at some point people starts to say that “tell business management about this.”
“But this is purely technical!”

I am not good at talking people coming from nontechnical backgrounds, and I find it quite interesting. They have eyes wide open, no idea what you are talking about; the literature you use is coming from MARS, and to take their attention and talking about the problems is not the nice part. However, when you start to talk about solutions, generally, it is a resource issue and it is hard to convince your needs/problems are really important.

From business perspective, I am sure everyone is coming with important things. And they have [hopefully well-known] priorities. They will take action based on the importance and relevance of the items.
What I can’t understand [or do understand but find it illogical] is that some companies have no roadmaps for some years. I find it harder to talk in a technology driven business that technological investment is in the very last rows of the priority list. 

In IT department, everyone is slow, not because it is UK, but they have no standards [or everyone has one].  Even the more process you create, the more slow you do your job, the more appreciation you get. If you deliver a project just to update a row for two months with three people, yes I am frustrated.

The business believes that if they continue what they are doing, they will be ok. They can be more than ok, they can be create state of art projects, but fine stick with the one we have and accept that “updating a row should take three people two months, and all a hundred documents are useful.”  UML documents are a subject for another blog, I do believe in documentation, but not modelling each call that creates a constraint for the creativity for the developer. Then don’t call him a developer but a code monkey. And if the strategy is outsourcing the overseas code monkeys, my questions are still valid that “technology driven business” [not software house] should have a core team in-house…

or not?

Role of the Software Developer

Who we call as software developer? After I see Burcu’s blog, the demand from the companies to be more specific, I had a second thought about the roles in real life… I find it hard to imagine a task specified on a distinct skill set on development environment. Even if my role is lead developer in an e-commerce business, and I have three business analysts, 2 project managers on my team, I can start coding after 5 pm; when people start to leave the office. The communication and maintanence tasks during the day becomes the most important thing, and there are plenty of meetings to discuss any new improvement/problem. After 5, I can have time to finish the projects’ task [coding].
Either the real life is simple, and I do not know the way to make it simpler or this is the most common path every developer faces. Since you are the most skilled person to solve the questions, your contribution is appreciated on many parts of the business. Lifecycle of the projects require lots of commitment and there are lots of challenges out there.

ISoftwareDeveloper
ISoftwareDeveloper

Projects:

  • Analysis phase can’t continue with a consultancy from a lead developer. Almost all meetings require the developer.
  • Design phase is done by the developer.
  • Developer is keener to create documentation [as a result of enough bad experience caused by not creating documentation and answering lots of similar questions]
  • Coding phase is the easiest part [smallest amount of time]
  • Meeting for testing scenarios phase starts. Creating data, simulating environments, solving problems with configurations/settings.
  • Deployment is always done by them…[even if it is not their project]
  • Testing with the help of testers and business analysts; then bugfixing starts.
  • When they think they can take a deep breathe, release starts; and after the release they have a brand new project!
  • During this cycle[regardless of they are waterfall or spiral, etc…] there backend tasks:

  • Deployments, code review [they are lucky if they are doing this; since this means candidate good develoeprs are on the way]
  • Merges of branches, and source control management are done daily. [not to mention conflicts and problems with builds]
  • Maintainance of the environments, and finding problems, solving…
  • Live issues, [emergent ones] need immediate attention
  • Ongoing support for ordinary questions/known problems[the ones we can’t solve not having budget/time]
  • Training/knowledge sharing with other developers.
  • The list goes on…
    Throghout eight years, I have not come up with a job that has only one task: coding.
    Development includes
    a system that is alive, needs attention all the time.
    people, requires communication, knowledge sharing
    projects, needs exploration of new ideas, as well as integration of old system with new one.

    What else do you developers do in your day?