I am a Software Developer, new business owner, and a bit of a quiet person. During the course of my career, I have come to realize that it is not enough to just write great software. In order to be seen and recognized, it is vital to be heard as well. Some may call it schmoozing, or even bragging, but - in order to expand your profile - you need to be vocal and visible as well.
Many times I have left it to Team Leads or Middle Management to send the communication to Upper Management or the Client. This is their responsibility after all, right? I didn't want to step on any toes, or make anyone angry.
The problem with that approach is that my own visibility was almost non-existent. Sure, my Managers and fellow teammates were very pleased with my performance, but outside of them, I was a ghost.
Since I started my new position at my current place of employment, I have taken a completely different approach. No longer am I the quiet one at the back of the room who keeps my opinions to myself. I now actively seek out and participate in meetings with Upper Management, Clients, and Vendors. I will make my thoughts and feelings known (with the utmost professionalism), and be the first person to send the message on new features, enhancements, and problems.
Could this cause problems? Could being vocal or having and communicating an opinion possibly lead to some negativity? It is possible, but I will remember that a turtle makes progress ONLY when it sticks its neck out.
#SoftwareDevelopment #BeVocal #BusinessPractices#ProfessionalDevelopment #CareerEnhancement
#PersonalDevelopment
http://www.blaazinsoftware.com
Tuesday 15 October 2013
Saturday 17 August 2013
Avoid Process Bottlenecks!
Don't let your processes interfere too much with the speed of Development.
Processes are vital to the success of any Software Development team. Most development tools even allow for restrictions to be placed in them to enforce workflows, practices, policies, etc. I once worked at a company that had their Issue Tracking software (JIRA in this case) configured to an 18-stage workflow process from the time an issue was opened to the time it was closed. Even worse than having 18 stages, several of those steps could only be processed by 1 person. If that person was busy, sick, or away for some other reason, the issue could not progress.
It is not surprising that this causes headaches. When the process stops (for whatever reason), the people involved do not. Worst case scenario is that they have to chase down the person they are looking for. Alternatively, they move onto other things (sometimes work related, sometimes not) which leads to more tasks being worked on at the same time. At first glance, this may sound like a good thing. After all, work is still getting done, right? That may be true, but this leads to other complications. As any juggler knows, the more items you have in play at any one time increases the possibility of a disaster. An interrupted task is estimated to take twice as long and contain twice as many errors as uninterrupted tasks (Czerwinski, 2004).
In an Agile work environment, the speed of development and quality of the software are paramount. So, put checks and balances into place to ensure software quality (preferably automated), and review any and all processes to allow for the software to be built as quickly as possible. Time is money, so wasted time is wasted money!
Randy May
Software Consultant
Tuesday 30 July 2013
How Much Business Training for Software Developers?
How much do Software Developers need to understand the business of the application they are developing?
Management and Business People tend to think big-picture (and that is a good thing). They view the application as a growing (hopefully) number of services to a set of customers making the customers' lives easier, and ultimately making the company money. Without question, this view of the application is crucial to the success of the application. Without this view, the services that are built may not fit together, may not be complete, or may be missing altogether.
So, how much of the underlying business do Developers really need to understand? How much time (and therefore money) should be spent on training Developers on what the application ultimately does?
When a Developer is building one of the above-mentioned services, they do not look at it as a piece of a larger number of services which form the application; they look at it in terms of what pieces of information are moving, what processing should be applied, and where that information should go. Depending on the nature of the data, this could be a database, a call to another system, mathematical processing, etc.
To Software Developers, an application is just an endless paddle-ball game of requests and data processing. The request comes in from the User, some data gets processed, and is then retured and displayed to the User. Request comes in, data goes out; request comes in, data goes out, request comes in... You get the idea. An application is a series of data requests, API calls, reads / writes to a database, display of data to a User, etc.
Remember, the same Developer can work on software that governs the fuel flow of a rocket one day, quantity of jeans on store shelves the next day, and a patient medication system the following day. Do they need to be a PHD in rocket phycics, Masters in Business, have their MD?
As a Manager, you want top notch Software Developers that can write great code with few issues as quickly as possible - regardless of what business you are working in. It is extremely beneficial that those Developers can transfer their skills from one subject matter to another; quality code is needed in rocket physics, retail, health care, etc. Taking time to train Developers on the business of the application is ultimately wasted time, and time is money.
You may be thinking that a Developer who has been with a company working on the same application for a long time is a benefit because they get to know the application and business the longer they work there. What is actually happening is they are remembering the application, not understanding the business. They will remember the services they worked on but that does not mean they understand the business. Plus, the longer a Developer is in the same place, they run the risk of having their skills become stale. Technology is moving at such an increasing rate that a Developer that is not moving forward is really moving backwards.
So, if you have a new Developer that has just joined your team, get them pair-programming with an existing Developer, and get them into the code as quickly as possible. They do not need days or weeks of training to get them understanding the business. They already know code; don't get in their way.
Subscribe to:
Posts (Atom)