Month: June 2009

bittnerness of failure

Tomorrow we will have the informal review session for the first increment [if you call it increment]. I had different kinds of challenges in this project, all team players coming from different backgrounds.  And always there is lots of to learn, bitterness of failure can be medicine for weaknesses.
1. Project scope was never clear as usual.
Lots of rework and change lists to go over many times [for models and code]
2. Team was not aware of how we are going to implement it. [Maybe some of them yes, but communication was not enough]
Incremental methodology should have been understood by project manager. All the project analysis phase is being done in six months, with one developer assigned. This developer was supposed to attend all the meetings, and tried to understand what she is supposed to be doing in six months. Analysts thought their task is over and they can wait for testing; delivered just UI specs. Developer was told to deliver models, design diagrams, code it, and keep up to date.
A project for more than a year, was planned in two increments [Increments were not really increments.]

Some people were complaining that the design documentation was not reviewed by analysts…[Can they?] Is this the point where waterfall becomes efficient? Something like spiral, but even if spiral, isn’t it the “working software” triggers analysis phase, not documents…

3. A new methodology called PSDM [an alternative version of RUP] was around to use, but no one had expertise. [Lots of hard work to understand how it is working with consultants, but they were mastering the project, lack of communication]
4. Roles were not definite [still not], and conflict of interests were stressful.
[Who should be the technical lead
-if we had one developer, why we would have one?
-if we have more developers coming on board, what is the role definition of technical lead? what is the expectation from him as technical details/giving support as well? if not who is going to the support?]
5. Analysis Model was done by the developer, [even consultants could not notice], and when she needed Design Model, she override the documents/system types. [No one was using those material, so no one has noticed…]
What is the point of creating documents….
Want to deliver “working software” frequently…

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?