Posted by Ian S. Nelson
Tue, 16 Oct 2007 23:13:00 GMT
I've had this idea for a book for most of this new century. I left IBM because I didn't feel as if my contributions mattered very much, I proceeded to go to less and less capable software shops where my contributions mattered more and more but not exactly how I wanted and regardless of what I controlled it seemed like more and more stupid things were done. There have been a few shining moments where the places turned out to be collectively more capable than I had thought and there have also been some disasters. After thinking about it, I came up with a plan for a book. My plan has been to record the foolish things I've witnessed over the years, and believe me, I've seen a lot of really stupid stuff, and then produce a tome on the subject and somehow contribute to the cannon of software engineering or computer science by suggesting ways to avoid the mistakes I've seen and even made.
I guess I believe, perhaps foolishly, that if we know our mistakes and why they were made then somehow we can do a better job in the future. The more I look at my log, the more it's looking like my book will just be a bunch of Dilbert-like case studies which isn't what I want. There are just so many really stupid ways to screw up software... While I reformulate my plan, I'm going to blog up some of the lessons I've learned, distilled down and without naming names. Email me if you have some stories, or post them here.
Here are some thoughts on staffing. One thing I've also noticed is that some of the most stupid mistakes are made with honest and sincere good intentions. This might just be a general rule for life, I've never heard someone talking about how they were intentionally doing something stupid, there is always a logic no matter how twisted and screwed up it might be. For example, it's never a good time to fire somebody, there is always a holiday or a release or something coming up, it's usually not a personal problem and you want their kids to have a good Christmas and all that cliche stuff. It just sucks. So I've witnessed the fear of firing turn in to a real joke, I saw a completely incompetent employee kept on the job until "the time is right" and work was fabricated for them. This isn't as easy as you might think, you can't just pull assignments out of a textbook when you do that, it has to apply to the job in some way. At the same time, you've decided to terminate this person and you probably don't want them further contaminating the code base. Once I saw a place hire a contractor to do a job and then put the person who was sitting on the plank on the exact same assignment in parallel with the expectation that they are throwing one copy of the work out. Then some half-brained decision was made to some how incorporate both of the projects because "dead man walking" was upset that we weren't going to use his code. His complaint was unexpected, it was as if he saw through the crafty ruse. So instead of just doing the dirty work, there was a debate on who had better code between an hourly contractor and a soon to be ex-employee who's team didn't want his code. As if Salomon himself decreed it, they cut the baby in half and used both code bases. Even better, the team that knew of the "weak link" had their morale drop because it started looking like they weren't going to replace the guy after all. And the project didn't work quite right either.
The lesson? I've come around and become much more cold blooded on this one. The best day to fire someone is today. If you have firing to do, then get it on. No good ever comes from putting it off. I'm not advocating just firing people because you're having a bad day or something but if you decide to part ways with an employee and you have made a good decision that is well reasoned and thought through, then once you've made that decision you should act. I don't think the people that work at that particular company are stupid, I know many of them are anything but that. Emotion got in the way though, it took a simple but somewhat dirty chore and turned it into an engineering problem.
Tags engineering, software, Termination | no comments
Posted by Ian S. Nelson
Sat, 09 Jun 2007 16:52:00 GMT
I recently went on a vacation to Scotland. While I was there, I read a wonderful
book about
St. Kilda and the near utopian society that lived there until 1930, it is no uninhabited. St. Kilda is one of the most remote Hebrides and it's a particularly rocky set of islands that isn't very easy to approach by boat. It had been inhabited for at least 2000 years and isolated from the rest of the world for most of that time. As a result the islanders depended upon each other a great deal. Everyone had a say on every issue, they shared resources, crime didn't really exist. And then the outside world crashed in on them, people started visiting the island as tourists and eventually the St. Kildans' culture fell apart and they asked to be evacuated from the island.
What was fascinating to me is that Kilda wasn't utpoian by design, it was by need. Everyone depended upon everyone else on the island of only a couple hundred people. There weren't people that just did nothing while other people caught food. (Also fascinating, they didn't fish, they were fowlers and climbed up cliffs and caught sea birds) Every single member of the society pulled their weight and did something that the whole group needed. They had no leader, they had a daily "parliament" in which every man got to talk and an equal vote. While it wasn't easy living, outsides that looked in described the society as a utopia. Even more remarkably, every person on the island was equal when in the rest of the British Isles clans and royalty controlled society.
I compare this to the software industry. At only two companies have I ever seen "the process" work. One was IBM and it worked because everyone was dedicated to making it work and there were a lot of full time process people that pushed the process through as well as a couple super heroes that did above and beyond the call of duty to keep things floating. It was very expensive to make software and, honestly, it wasn't the most fun I've ever had. The other was a small startup where we had almost no management and a very tight team of developers and testers that all wanted to make the company successful; the executive staff was completely hands off. People didn't simply do their job and throw some output over the fence, everyone did more than their job description and there was almost no outside pressure in and we were fairly Agile and had enough process to provide some safety nets but we moved quickly. Also, everyone on the team didn't know anything but success, there was a lot of pride and "good enough" wasn't good enough for us and it was great while it lasted.
Everywhere else, they pretended. Process wasn't a need, so much as an excuse. (The lack of any process is the same thing, it's a process in its own right and there are usually bullies somewhere in the organization and it involves some sort of punishment feedback loop) I had this great experience once where I was encouraged to push back, but not until I exhausted every other option (that meant working 10+ hours 7 days a week, or at least that is how it was measured when you did "push back..") which is silly because it requires you to actually fail to prove that the plan didn't work in the first place. I'm watching it on a great scale now, there is a great effort being made to appear to follow a process but there really isn't one. It's easy for everyone to "do" the process but simply "doing" it doesn't make the product better or reduce risk or really even mean much of anything. It requires collective discipline, collective sacrifice and compromise, collective give and take and a lot of trust. Everyone in the organization has to take part, every single stakeholder has to be part of it. No process can create time when there isn't any or make an average team in to a great team. It's easy to pretend though. I'll talk more about that next time.
Tags agile, engineering, PACE, process, processes, software | no comments
Posted by Ian S. Nelson
Mon, 21 Aug 2006 23:51:00 GMT
Does security need to be baked in to a product from the very start? Or can you add it after the fact? Does the development model affect this? I think this is a really interesting question. My instinctual answer is that to build a properly secured application or system of applications you have to plan for it from the start. That's the parochial answer and I'm not sure that's it is 100% correct. The last few years various iterative development models have become more popular and while I cannot point to any examples of great success coming from that I also can't point out any failures that could have been avoided with any other development model. The trend is to rapidly develop with little or no up-front design, adapt to changing requirments dynamically and rapidly fix problems as they arrise. Do these development models lead to less secure products by their very nature?
The logical follow-up is how do you iterate security in to a product after the fact, if that's a valid way to do it? Any thoughts or experiences?
Tags engineering, security, software | 2 comments | no trackbacks
