Attila Buturla

Creating working software is relatively easy. Creating high quality software that exceeds expectations is hard. In my last two blog postings I've discussed the challenges of managing software projects, in particular when dealing with external customers. On the one hand a customer wants to know how long a project will take and how long it will cost. On the other hand we simply don't have accurate ways to measure how long a project will take, due to all of the variables involved. One can try traditional project management techniques to pretend to know how long a project will take, or one can use agile techniques which don't lend themselves to determining the cost all up front. I fully understand why a customer wants to know how much something will cost. When I go to my mechanic with a problem, they provide me with an estimate of what they think is wrong and how much it will cost. Of course once they pop the hood and start working they often find unexpected issues, and the...

In part I of my blog posting on estimating agile projects, I discussed how a prior employer attempted to use waterfall techniques to ensure that customer's projects were delivered on time and on budget. In the end the waterfall project management techniques added a lot of overheard with negligible benefits. Of course this was just one company's experience. Having said that, I worked for several more companies that also used waterfall techniques and those techniques rarely resulted in software projects that were on time and on budget. On the contrary they added a lot of overheard and did little if anything to improve the quality of the software. Within the last few years agile practices, including Scrum, have become common place in software development. I first used Scrum about seven years ago, and immediately saw the benefits. The focus was on producing usable software, while detailed specs and projects plans were no longer needed. At the time I worked for a company that was...

Over the course of fifteen years as a software developer, I've worked for nine different companies. They ranged in size from under fifty employees, to over a few thousand. They spanned many different industries including financial, medical, retail/e-commerce, and custom software development.  While they each differed in many ways, one thing was constant; as software developers we were required to provide estimates for how long it would take to develop our software. In particular, three of the companies that I worked for were software consulting shops. By that I mean we wrote custom software for our customers. In these cases getting software estimates wrong didn't just make the team look bad; they could be the difference between the company making or losing money on a project. If too many projects were underestimated, it could potentially result in financial hardship for the company and ultimately even layoffs. The first software consultancy that I worked for was back in 19...

Meetings ... love them or hate them they are a part of everyday business life. I've had multiple bosses that detested meetings, saw them as a waste of time, and would dissuade us from having them. On the other end of the spectrum I've worked for organizations that had countless meeting, many that were of little relevance to me, and left little time in the day to accomplish my other duties. In this posting I aim to examine the cost and benefits of meetings, and also touch upon what it takes to have effective meetings. As someone that has worked as a software developer, team leader, and manager of developers over the years, I'd like to think that I've seen the good and bad side of meetings. Let's start first with the cost. Everyone would agree that a 1 hour meeting requires at least an hours worth of time for everyone that attends. Add to that the need to break ones focus from what they were doing, and regaining that focus after the meeting, you may even raise that ...

Over the past 13 years I've worked as a software developer, team leader, and manager at seven different organizations. Each was different in size, industry, and organizational structure. I'd like to think that at each job I've learned from what they did well, and possibly even more so from what was done poorly. While software development is not a new profession, compared to that of others it's still in it's infancy. While there are many different areas that one could focus on, I think one of the more interesting (to me at least) is what the role of a manager in the software field should be. Let me start off by setting a few things straight. In some organizations, especially ones in smaller companies, a manager may be involved in software development. However, I don't consider that person to be a true manager. The more appropriate term might be lead developer. If a manager is involved in software development, but that is not the focus of his or her role, then o...

Some of my friends told me that they enjoyed my blog posting titled "How to run your IS department", although I did hear a consistent message in their feedback. While they seemed to agree with the content of my posting, the general sense was that it sounded like I was complaining without offering any concrete solutions. Well, I'm glad to say that I already had solutions in mind when I made the original posting. Let me start of by saying that I'm not claiming that these ideas are 100% mine because they're not. Rather, they mostly stem from other sources that I have gleaned over the past year while trying to learn more about Scrum and other best practices. Never the less they will help any leaders that are trying to improve how IS is viewed by their organization. Get People Outside of IS to Sponsor Your Projects In Scrum that is the role of the Product Owner. IS rarely creates projects solely for themselves; rather the project has some value to the bus...

Over the course of being a software developer for the past 10 years, at 5 different employers, I've noticed a reoccurring problem at these organizations. The business leaders simply don't understand what IS does and the value that they can bring to the company. (The one exception being a software consulting company, where IS was their business.) Most organizations tend to see IS in a similar light as brick layers or plumbers. They are simply there to keep things working. Additionally they are there to build what other business leaders have envision. In this analogy the business leaders are the architects, coming up with the grand designs, while the software people are the construction workers, putting the pieces together. What the business often fails to realize is that role of IS is to help the business run more efficiently, increases company wide productivity, and most importantly be a strategic asset to the company. In all of my working experience, the software...