Small is Beautiful

1. Small is Beautiful Michael (Mike) Williams AKA Grumpy Old Man

2. Small or Large? • Most software projects are small • Less than four people • I guess that most of you in this room do small projects • A few software projects are very large • Several hundred people • For the last 15 years I have been working with and managing parts of very large projects

3. Why are they large? • Complete hardware systems • Special purpose hardware for signal processing, control and communication integrated together. • Fans, power supplies, cabinets

4. Why are they large? • Most software written from scratch • Signal processing • Protocol handling • Traffic set up and control • Resource handling • Adaptation to low level operating systems • Remote supervision and configuration • Remote loading and upgrade of software • Hard real time and soft real time • And more

5. And it must all work, all of the time! • People’s lives depend on our systems working • Can’t stop the system for maintenance • Equipment is in places which is hard to access • Any faults must be corrected with only tiny (unnoticeable) outages • Upgrades must work

6. A Dilemma • Virginia Tech Carilion Research Institute • Working in groups drastically reduces our intelligence and ability to think logically • http://research.vtc.vt.edu/news/2012/jan/22/group-settings-can-diminish-expressions-intelligen/ • Coordination of the software in a project with hundreds of people requires • Working in teams (groups) • Many meetings

7. A Dilemma • How can we work in large projects so that work is done by individuals and the “dumbing” down effect of working in groups is avoided?

8. Design in small increments Design increment Requirements We round this cycle many times during a SW developmentproject. The faster we cango round the cyclethe more efficientit will be. Anything which delays the cycle, anywhere delays the whole project Test / Verify Correct / Improve Deliver Increment

9. Design increment Requirements Test / Verify Correct / Improve Deliver Increment In reality • Lots of small parts developed • independently • but coordinated • and tested and integrated together

10. The hard things • Each part (feature) must be as independent of other features as possible. • But features do interact with each other! • We need a common architecture and design principles. Somebody is going to have to maintain the system in the future. • We do need an organization. • Design teams with a small number of people (minimize the dumbing down aspects) • A very few top level architects • People to integrate and test the whole system

11. Key aspects Clever people • We have to have • Clever people • The right Organization • The right Way of working • Appropriate technology • To make a good system Organization Way of working Technology

12. Erlang/OTP - ideal technology for the soft real time parts of the system • Load code into running systems – No build times either when integrating / testing parts or when integrating / testing the whole system • Test set up times minimized • Easy to debug / trace to find bugs • Dynamic language with symbolic information available • Distribution part of the language • Easy to debug/test distributed systems • Compact code • A few people can design a large part of the system

13. And for the systems I work with • Easy to define error handling code • For hardware failures • Recovery from software faults • Erlang is a lot simpler than C++ or Java • Easy to teach new people • You can concentrate on developing software not fighting the language

14. But what shouldn't you tell your manager?

15. Nobody (so far) has invented any reliable way to measure productivity of SW development. Do we ever develop the same SW twice with the same pre-conditions? All attempts to use formal methods to derive software from requirement specifications break down as soon as we try to use them on realistically large and non-deterministic systems. The same is true of attempts to formally prove the correctness of programs. The most commonly used paradigm for SW development is “trial and error”. SW developers have almost religious beliefs in which operating system, programming language, editor, etc is best. If you are going to produce “art” you needs the best tools - Erlang SW development is an art, not a science Mona Lisa Leonardo da Vinci

16. Managers dream about “Software factories” Estimating the needed time to develop software is an art! Lots of people, who have hardly done any programming at all, believe in wacko methods which are supposed to increase productivity There are as many ideas about good programming style as there are programmers! Don’t tell you manager that your work is “trial and error”, doesn’t sound very professional Because SW development is an Art: Going to work - Lowry

17. Your boss may be worried about funky functional programming languages Lot’s of pointy headed managers think object orientation is the same as development efficiency. Managers never get fired for following old trends (Java, C++, Micro$oft etc) So just tell you boss that Erlang/OTP is used for financial and banking applications. Banking always seems solid – despite Leman Brothers! It’s Not Object Oriented

18. You don’t want your job to sound too easy, hard work means more pay. Best to say, “yes it’s hard to learn, but learning it will make me so much more productive” (I.e. pay me more for being so clever) But the fact is to truly understand Erlang is a heck of a lot easier than “C” or “C++” i = 10; j = i++ + i; What is i? 20 or 21? Erlang has left to right evaluation, in C it’s not even defined! IT’s EASY to LEARN Machine for knitting socks

19. Lots of managers are worried about open source. People doing anything for free is communism! If this comes up, just ask you boss what “C++” compiler you are using. The odds are ten to one that it is gcc. DANGER: You boss may not know what a compiler is. In this case, you need not worry – your boss probably won’t know what Open Source is either It’s OPEN SOURCE

20. IT’S EASY TO INTERFACE TO OTHER LANGUAGES • This is the same as worrying about Erlang not being object oriented. You don’t want to make your job sound too easy. • The recent management trend is to think that software can always be developed using reusable components. • Your boss may insist that you use some vastly expensive database, GUI builder, management system. • Play it by ear. • Saying it is easy to interface to other systems may mean you are forced to use some wacko components • Say it is hard to interface may mean you won’t be allowed to use Erlang • This is difficult Re-use isn’t free, it costs a lot more than the “purchase price” Architectural Salvage – Hardware “Re-use”

21. YOU WON’T NEED SO MANY PROGRAMMERS • In many companies the status of a manager depends upon how many subordinates you have • If it is easy to program, you won’t need to many programmers • You had better keep very quiet about this one! Fred Brooks Brooks’s law: Adding manpower to a late software project makes it later

22. C++ and Java are Unnecessary • If you want to do really low level stuff you may need to use assembly language • If you have hard real time, or need to write device drivers, virtual machines etc, C is a good choice • If you are into scripting then you can use Perl, Python etc • If you want applications you have Erlang, Haskell, OCaml, Sceme etc • What the heck are C++ and Java good for?

23. Just to Summarize • Using Erlang is a very good idea – if you have an application which suits Erlang • But new approaches always meets some opposition from “pointy haired managers”  Good Luck!